Modularity is the ultimate agile tool!

The Title of the article might sound a bit too bold to catch you attention, but let me elaborate on this. Modularity in Software Systems means composing a system of a set of a loosely coupled and highly cohesive components ako modules. A good example of a loosely coupled, highly cohesive architecture is s.c. Unix philosophy, which is summarized as by McIlroy¹ as follows:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Todays Microservices trend pushed that idea again in the foreground so people begin reasoning about such things again. But what that have to do with Agility? Let’s remember some of the 12 principles behind the agile manifesto first.

Principles from the Agile Manifesto (excerpt)

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.

Let me summarize that as:

The ability to deliver software systems constantly, every day, several times a day, or if you need, at any time it’s needed - is agile thing!

Having such speed and flexibility in the delivery to the customers needs, is the current maximum of the Feedback Loop you can theoretically get! But to have this you need not only the Mindset and Organizational changes. What follows are the changes in the Software Architecture Style and Technical decisions you and your organization make.

Modularity is agile

Speaking of technical design, we need to think which systems are more suitable for this. It’s obvious to me, that modularity helps here a lot. Theoretically, a modularized software project will be more easily assembled, since no team members are creating the whole system, or even need to know about the system as a whole. Design in modules allows the developer to confine his changes to one or a few modules and speed up the build and testing of changed parts. Of course, this is not an automatism and you need to follow some guides. For example, if your tests do follow Mike Cohn’s Test Pyramid² pattern, then you probably profit already automatically here. But even without speaking about testing (which can be a very long topic) modularity reduces risks of bugs in production. Consider a system that designed and changed according to prominent and commonly accepted rules like loose coupling, stable API etc. If changes were made to only a few modules not violating API and interfaces, the risk of going live should be reduced.

In the best case, modularity is taken to the level of microservices, important here is the definition of microservice as separate deployable (independent) process with own and widely independent build and deployment cycle! Having that, a (Micro)Service can be seen as a run-time unit of modularization and thus adding to you’re delivery speed. Well technically there are still a lot things that can be done wrong so unwanted dependencies will arise unconscious or even negligent. This article is not about thechnical pitfalls. I’ll try to come back to such details in one of the next.

Finally, to resolve all doubts, I think that agile companies/teams become agile not because of tools or architectures they use in a first place. Agility starts with a mindset, communication, and organizational issues. But at some point, you need to find architectures and tools that support you’re doing that successfully. Prepare your’ mind for new strategies, tools and practices.