Why do large systems disintegrate? The process seems to occur in three steps, the first two of which are controllable and the third of which is a direct result of our homomorphism. First, the realization by the initial designers that the system will be large, together with certain pressures in their organization, make irresistible the temptation to

Domain-driven points out that a business drives results through investments in knowledge acquisition within and beyond its current sphere of influence and activity. The business drives its own advancement and growth through steady improvements in its technology-based products. This book continually asserts that it is learning through experimentatio

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.

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.

When the team has decided on modules first, and when deployment options start out as simple as possible, that approach puts them on solid ground to make decisions based on empirical information at the most responsible time.

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

The greatest innovations have come from relentless experimentation coupled with continuous improvement.

Assertion: Those who want to build good software that innovates must get this communication–learning–innovation pathway right before trying anything else.

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. T