Posts Tagged modular

A while ago I posted here about the role of the architect when building lean software. Inspired by posts by Kirk, Hal and Joel, I’d like to build a case for selecting the right tools and frameworks in order to be able to sustain your agility in the long run.

Starting with the opening argument that Hal makes, we’ve all been in projects for long amounts of time, where at one point you start wondering what became of that once beautiful and comprehensible design, or those fast build and test cycles you started out with. As products evolve over time, they all seem to loose a lot of their initial “elegance” up to the point where people seriously start considering starting from scratch “because it’s easier than bolting on new features to the existing product”. Apart from the fact that that is very counter-productive from the point of view of the customer, you’re also throwing away a lot of experience, especially if the original authors of that code are no longer around (which sometimes is stated as a reason to start over). Joel made a case for not starting from scratch and raises some very valid points there.

So, if it’s not smart to start from scratch, and you really want to sustain that agility, how are you going to make that happen? There, going back to one of the points that Kirk makes, a lot depends on your architecture, especially if you look at it from his point of view:

The goal of architecture is to minimize the impact and cost of change. To do this requires we create flexible systems with the ability to adapt and evolve. But with flexibility comes complexity, presenting architects with a paradox. As we design more adaptable systems, the additional complexity reduces their ability to survive. Eventually, the software rots, the architecture crumbles, and the system fails. Therefore, we must find a way to increase adaptability without decreasing survivability.

Combining observations here it becomes increasingly important to stay modular and to really try hard to loosely couple your components because that has tremendous benefits in the long run. Doing that is not easy though, as it requires a lot of thought, and you might need to make some other trade-offs in favor of modularity and loose coupling. However, it is one of the few ways that allow you to make decisions that are always reversible, as ripping out a single component in an environment where there are as little dependencies as possible and where each of these dependencies have small and substitutable interfaces remains as easy as it was when you started the project. In practice it also means that it is worthwhile ensuring that these qualities in the overall architecture do not deteriorate and that you spend enough time making sure they don’t by refactoring and reviewing code as part of the normal development cycle.