Additive modularity

One aspect of modularity is the ability to add modules without disturbing existing modules. I call this property “additive modularity” (unless you know a better term.) In software, it’s often easier and safer to add something rather than change or remove something.

Functional programming has the concept of immutable data. Additive modularity is like extending that concept to code and running systems, at least partially.

Changing or removing modules means the consumers of those modules all have to change too. If you only add, then existing consumers remain undisturbed. An example of this is the Stripe API, which maintains previous versions of its API and lets consumers upgrade at their own pace.

Changing or removing data erases history. Adding data preserves history. If you have a domain with auditing requirements, a typical way to do that is to add immutable history entries every time something happens. Some of those entries can correct previous entries. For example, say your system deals with legal contracts. If you have a contract that needs corrections, then instead of erasing the old contract file, create a new file and mark it as a correction to the previous file. That way, history is preserved.

Changing code can result in bugs. One way to reduce the risk of breaking anything is to build new functions/methods/routines rather than touching existing code. This may lead to code duplication, but you won’t need that old code once you switch over to your new stuff anyway. For example, say you have to make some fairly major changes to an existing API. Rather than change it, add a new code path and serve it up as a new API. Then use a feature flag in the consumer to switch to the new API when ready.

Similarly, blue/green deployments reduce risk by not changing existing servers all at once. Rather, the deployment creates a “green” environment, tests it, switches traffic to it after testing, and deprecates the original “blue” environment.

So, when faced with the risks of evolving a production system, consider whether it would be simpler and safer to add rather than change or remove.