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.


Faster load times for free

What if I told you there exists a simple method to start saving money on servers today and that takes only one line of code to implement would you believe me?

Well welcome to the world of headers, for followers of my blog this is more like an expansion of what we had talked about a few months ago Using status codes and headers

In this entry we are going to talk about the headers that we can start using to reduce server-client communication immediately which has the double benefit of

  • Saving your customers especially those on mobile data charges
  • Reducing the work your server needs to do


The Etag provides a unique representation of the response issued by the server. It is usually a short string that is of meaning to the server. You probably already have unique ids for data entries in your application, this would act as good targets for an etag if however entries are editable you may choose to use a hash of the content.

\\Code example in Laravel PHP


return response($content)
            ->header('Etag', $etag);


An Etag is not of much use if the client doesn’t make use of it. The If-None-Match header allows the server to return appropriate responses for the data if content still there.

use GuzzleHttp\Psr7\Request;

// Create a PSR-7 request object to send
$headers = ['If-None-Match' => '897696a7c876b7e'];
$request = new Request('GET', 'http://yourservice/blogs/57', $headers, $body);


This instructs the client and all other downstream services if the content can be cached.

The main settings for it include:

  • private Instructs cache is specific to a user
  • public Can be cached for use by all clients
  • no-cache Client must re validate all requests
  • no-store Client should not cache anything at all

There are more settings and you should check them out

return response($content)
            ->header('cache-control', 'private, no-cache');


Nothing lasts forever, even data. As such makes sense to inform clients of best by date for the data they have cached. In modern browsers you could use max-age control in the cache-control header.

#Example for django

response = HttpResponse()
response['Expires'] = "Thu, 24 Sep 2015  12:00:00 GMT"


As you get more sophisticated in your caching techniques it may now be time to start using the Vary header. The header allows clients to know if they have valid content based on some condition.

The most obvious example would be if you serve different content for mobile and notebooks then the browser should first check if the cached content is of the same user agent

#Example for ROR

response.headers["Vary"] = "User-Agent"


It is important to note that not all clients respect headers but for those who do, you would be doing yourself and them a world of favor by providing them with appropriate headers

Will you be implementing the headers we have talked about? Talk to us on the comment section below.