Isolating Change In Software Projects

Software more than any other human creation has had the largest impact in human society in a very short period of time.

It’s strength lies in its softness that is the ability to adapt, reuse and even re purpose existing software to build better and better products for cheap. But hidden in this strength is a weakness, change very quickly degrades systems to a mess no one can understand. As we have already discussed before in The heart of software engineering this kind of complexity is the death knell of the project.

Our best defense against this particular blow is to actively manage the areas which our software is likely to change. As such I have prepared a tickler list of such areas as I have experienced in my own practise.


From File based to relational to object oriented to NoSQL, the world of persistence has changed a lot in the last 15 years. If your codebase was tightly coupled to any one of this paradigms, at best the product may not be taking advantage of advances in the field at worst it may have already been wiped out! Yet the effects are not always so grandiose, sometimes you may realize that another database in the same paradigm may serve you better, say Postgres over MySQL for GIS data.

For this reason it makes sense to decouple your code from your DB. This is usually the easiest to do because any good ORM would do the trick.


Better hardware comes out every year, I am not talking about just Moore’s law but rather entirely new hardware or new specifications for existing hardware.

You should wrap all code that interacts with the hardware in a class or module then access that via a standard interface. That way you can easily switch out implementations as need be.

Business rules

Business that thrive have learned the value of evolving to adapt to the current trends in its industry. The product owner will expect the codebase to evolve to meet the changing business model.

The topic of adapting your code is covered well by Eric Evans in his book Domain Driven Design. This is a must read for anyone engaging in the business of software consulting.

However we can still take care of the basics including things like

  • Giving meaningful names to entities in your application
  • Encapsulating business rules in classes
  • Accessing constants such as tax rate from environment variables

Framework dependency

It’s considered heresy to write code without using a framework. Countless flame wars have been waged on the topic yet what the commandos in this war fail to see is that a framework is just a set of libraries meant to support your code. You should wrap any exotic functionality provided by the framework in packages or at very least define interfaces which then the framework would support. Otherwise when a better framework comes along the cost of the transition maybe prohibitive and your project will thus be married to its original framework.

Have you identified other areas in your code that seem to change frequently? Talk to us in the comment section below.


The heart of software engineering

TDD, BDD, Design patterns, SpecDDD this and many more are terms to be discussed whenever you step into any conversation centered on best practices. What if I told you that they all related and are all an implementation of one basic principle?

In On the cruelty of really teaching computing science Dijkstra famously points out

    Compared to that number of semantic levels, the average mathematical theory is almost flat. By evoking the need for deep conceptual hierarchies, the automatic computer confronts us with a radically new intellectual challenge that has no precedent in our history.

Still with me? By now you may have already guessed it. All Engineering practises are driven by the need to manage complexity in software

So what do I mean when I say manage complexity? Well that means trying to cram an entire program/application into your head is an exercise in futility but rather we build tools (JUnit, PHPUnit) to check functionality of our code and even better we organize our code in such a way that we can safely focus on only one part at a time (Design Patterns).

So what can we do with this knowledge of the basic principle guiding software engineering? For one we can come up with some rules of thumb in evaluating our design choices, remember we have talked about their wickedness in the past.

Rules of thumb when making design decisions

  1. Always select the simpler design
  2. Always assert inputs to ensure that your simple design covers all business cases
  3. A simple but wrong solution is useless
  4. Minimize contextual knowledge needed to understand your code at any point

There we have it. How have you dealt with complexity in your own projects? Talk to us on the comment section below.