#begin
Chapter 9 kicks off Part 3 of the book, which David calls “Optimize for Managing Complexity”. After all the chapters about the right mindset for learning, iterating and experimenting, Dave now shifts gear into the design principles that help us keep our systems under control. And he starts with modularity. No surprises there.
Hallmarks of Modularity
David opens by defining what a truly modular system actually looks like in practice. A modular system has components with well-defined boundaries, minimal knowledge of each other, and the ability to be changed, replaced or tested independently. If you change one module and it breaks three other modules, you do not have a modular system. You have an illusion of one.
I think this is a good framing. Many teams think they are building modular software because they have folders, packages or services. But folders are not modules. The hallmark of real modularity is the ability to isolate. Can you test this thing on its own? Can you deploy it independently? Can you understand it without reading the rest of the codebase? If the answer is no, it is not truly modular.
Undervaluing Good Design
David makes a point here that I feel quite strongly about: the software industry consistently undervalues good design. There is always pressure to deliver faster, to cut corners, to just get it working. And good design is often the first casualty.
The irony is that poor design slows you down in the long run. A codebase that nobody dares to touch, where every change takes three times as long as it should, where bugs breed in dark corners of tangled dependencies… that is the real cost of skipping good design. David is rightfully frustrated with this and I share that frustration completely.
The Importance of Testability
This is where David gets to something I think is genuinely underappreciated: testability is not just a nice property of your code. It is a direct indicator of how modular your code is.
If you cannot write a unit test for something without instantiating half the application, your design has a problem. Testability forces you to think about dependencies. It forces you to define clear interfaces. It forces you to separate concerns. In other words, writing testable code and writing modular code are essentially the same activity. If your code is hard to test, it is hard to change. And if it is hard to change, you are in trouble.
David goes further and argues that you should design for testability from the start. Not as an afterthought. Not as something you bolt on after the feature is done. Testability should be a first-class design goal. I agree completely. The teams I have seen that treat it this way consistently produce better software than those that do not.
Services and Modularity
David addresses the common misconception that modularity means microservices. It does not. Microservices are one way to enforce modularity by making the boundaries physical and explicit through network calls. But you can build a perfectly modular monolith, and you can build a horrifying distributed ball of mud that happens to use HTTP between its components.
What matters is whether the boundaries are real and respected, not whether you have separated things into different processes. I have seen microservice architectures where every service needs to know the internal details of every other service to function. That is not modularity. That is distributed coupling, which is arguably worse than the monolithic kind because it is slower and harder to debug.
Deployability and Modularity
An interesting angle David brings in here is the relationship between modularity and deployability. A truly modular system should allow you to deploy components independently. If every deployment requires coordinating twelve teams and releasing everything at once, your system is not actually modular regardless of how the code is structured.
This connects directly to Continuous Delivery, which is Dave’s other great passion. Independent deployability is one of the most concrete tests of whether your modularity is real. It also has enormous practical benefits: smaller releases, less risk, faster feedback. All the things we have been talking about throughout the book.
Modularity at Different Scales
What I find particularly valuable in this chapter is that David does not limit the discussion to code-level modularity. He applies the same thinking at different scales: the module level, the service level, and even the human system level.
Teams are modules too. The same principles apply. A team should have a clear purpose, well-defined interfaces with other teams, and the ability to work independently without constant coordination. Conway’s Law is always lurking in the background here: your system architecture will tend to mirror your organizational structure, whether you like it or not. So if you want a modular system, you need modular teams as well.
Takeaway
This chapter reinforces what we have been building up to throughout the book. Modularity is not a stylistic preference or a luxury for teams with time to spare. It is a fundamental engineering discipline. It is what allows you to keep moving fast as your system grows. It is what keeps complexity from compounding into chaos.
David has made the case before in earlier chapters, but here he goes deeper and ties it to testability and deployability in a way that makes the argument much more concrete. Good modularity is measurable. Can you test it? Can you deploy it independently? If yes, you are on the right track. If not, you have work to do.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments