The Pragmatic Programmer, by David Thomas and Andrew Hunt, gives useful names to ideas such as keeping knowledge authoritative and designing for change. The interpretations here are mine; the publisher maintains an official reference to the book’s tips. Two choices in the current warehouse project show why those ideas matter and where they create costs.
One packaging definition
A packaging conversion changes both the quantity an operator enters and the base quantity inventory records. If receiving, inventory, and reporting each define that conversion, the system can produce several internally plausible answers.
The current design therefore treats one packaging definition as authoritative and gives conversion a testable path. That concentrates the rule, but it also concentrates dependency: changing a package definition can affect historical interpretation, validation, and every workflow that consumes it. The rule needs an explicit change path rather than a convenient local copy.
A modular monolith for the current boundary
The WMS currently uses a modular monolith. Receiving, putaway, command replay, and inventory updates can remain inside one application and local transaction boundary. The deployment shape fits the current inbound prototype and keeps failure handling direct.
That choice has costs. Modules share a release and runtime; a resource problem can affect the whole application; and boundaries depend on code structure and review rather than network isolation. Independent scaling is limited. Splitting services would trade those constraints for network failures, distributed coordination, more deployment paths, and more observability work. The project does not yet have evidence that those costs would improve the system.
Evidence sets the claim
A small vertical workflow is useful only when the check proves the path it names. The WMS browser verification now starts with open work and ends with an independent state check. Its recorded button-driven path completed; Enter-key and physical-scanner acceptance remain unresolved.
That is the pragmatic test I want to keep applying: make the rule authoritative, choose the simplest boundary that protects it, and state only what the evidence supports. The related UAT record shows what changed when the browser contradicted an assumption.
← All writing