Spaghetti business always exists before software, and spaghetti code is the bane of a system’s existence. Ad hoc architecture, progressive distortion of the software model, wrongly chosen abstractions, seeking opportunities for code reuse before use is even achieved, and unskilled developers are some of the reasons that software complexity prevents

In the end, making some decisions early on is irresponsible. For example, settling upfront on architecture, such as using Microservices, or trying to create generalized solutions and modeling abstractions, is wrong. These decisions should be postponed until we prove that those choices are justified and necessary.

Early on, it is best to choose a deployment option that supports fast experimentation, implementation, and delivery. This specifically points to using a Monolithic architecture in the early stages, because trying to solve distributed computing problems before the business problems are understood is an act of futility.

The quickest way to deliver the best outcomes for users is by driving in the straightest possible lines of incremental improvement. Select from the best service-level architecture and deployment options based on full knowledge of need and purpose.

Conway’s Law doesn’t leave anyone guessing about how to make organizational communication structures work for the greater good. As the conclusion of Conway’s paper states: We have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.

This is a good place to introduce the idea of using an engineering model approach to software development as opposed to the contractor model. First consider the typical contractor model. Under this model, whether used by employees or actual contractors, developers must be given accurate tasks to work on, and they must not fail in even small ways.

Even so, problems will occur when trying to apply Bounded Contexts with distributed computing before the teams have a good reason to, or when trying to understand the strategic goals and solve business problems using single-process modularity first. Such a bias will likely lead to over-engineered technical approaches, putting too much emphasis on

So you can’t go out and ask people, you know, what the next big thing is. There’s a great quote by Henry Ford, right? He said, “If I’d have asked my customers what they wanted, they would have told me ‘A faster horse.’” —Steve Jobs

As an example of using a methodology or process execution framework, Scrum identifies four primary reasons to place an item in the product backlog: Features Bugs Technical Work Knowledge Acquisition It’s disappointing that Knowledge Acquisition is consigned to last place, because it should always be in first place. How can a team place a new