Advantages Of Hard-To-Change Software

Photo by Yogesh Patil on Unsplash

Maybe it’s not always advantageous for software to be easy to change.

Several years ago, I worked as a programmer for a software product company. This company sold a system where Goods and Services Tax (GST) was calculated in as many as 50 separate places. In some respects, this was a good thing. If I introduced a bug and broke the GST calculations in one place, GST was still correctly determined in the other 49 places. That’s a 98% hit rate. Not perfect, but pretty damn good. This software system was robust and maintained much of its correct operation even when a developer was sloppy and introduced mistakes. What’s not to love?

As you can imagine, this desirable system property of ‘robustness’ is all nice and good until we must modify all GST calculations. Now we are forced to make code changes in 50 separate places! Ouch.

The perceived system robustness cuts both ways: It prevents programming errors from spreading throughout the system yet also inhibits desired system modifications. 

What if the GST calculation resided in one place? It would be easy for us to break all GST calculations by introducing a bug. On the other hand, making necessary alterations to GST would be easy too!

What are we to do? Which situation is more beneficial?

Having the choice to make changes to software quickly is a desirable quality. So is knowing that we cannot easily break the system when we introduce a programming defect. 

Is there a way in which we can get the best of both worlds? That our software is robust but also easy-to-change?

Yes, there is. But it means we need something more than simply the system implementation code. We could have a ‘fragile’ system insofar that changes made in one place alter specific behaviour throughout the entire program. As long as we have ‘tripwires’ set up informing us of erratic program behaviour, we can live with a system’s ‘fragile’, easy-to-change nature. 

And what are these ‘tripwires’? They are automated tests, mostly unit tests. 

We want to build easy-to-change, and thus easy-to-break, systems. However, if we utilise tests to verify correct operation, we will reestablish system robustness.