The SquizLog

A Rant about Software Entropy

I've just spent the best part of today fixing a software bug that shouldn't have seen the light of day.

The fact that it did was due to another developer's decision to do some "refactoring". Notice that I put the term refactoring in inverted commas. Why? It all has to do with the definition of refactoring, which is to improve the design of existing code whilst preserving its behaviour. To put it another way, make the code better internally without altering its external function.

And, as I have asked my students in the past, how do we ensure that the software still functions the same way externally? We test, of course, don't we? Sure. We test before and after to make sure it all still works. All still works? How can we be sure that we test all the scenarios that could be impacted by the code changes we are making? Think about it. Unless we're careful things can rapidly get out of hand.

A couple of things are very important here. One is the ease of testing enough relevant scenarios quickly. Another is the risk of making too many changes before testing all our scenarios again. This is where automated testing really comes into its own. If we are disciplined, we will continuously extend a suite of automated tests that provide reasonable coverage of the scenarios. We will build up suites of automated unit tests, integration tests and functional tests. And we will pay particular attention to automating tests of the user interface or, at the very least, tests of an interface very close to the user interface.

Now, what has the preceding couple of paragraphs got to do with the bug that I fixed today? Notice that I used the word disciplined. I think that is a very important word in the context of developing software. It is so, so easy to develop without the discipline required to ensure that software does not decline into a state of disorder. The discipline required to ensure that when we, with the best of intentions, change the internal design of our software we do not introduce bugs that displease the customer.

I am reminded of a task that I completed in my first job out of university. This was back in the early 1980s when, having learnt Pascal and UNIX at university, my first programming job introduced me to the wonderful world of IBM compatible mainframes - a world of PL/I, CICS, IMS DB and JCL. Even in those distant days the importance of regression testing was recognised by some. One of my tasks was to develop and document a regression test suite for a revenue accounting application. I was very proud of the result and naive enough to think that I had made a worthwhile contribution. What transpired? Nobody used the regression test suite. Nobody! I guess that would have taken too much discipline.

Maybe I'm being unrealistic in expecting software professionals to test professionally. Maybe I'm wrong and it is all too hard and too time consuming. Maybe I should go with the flow more and accept the work practice which says: "Does it compile? Yes? Then let's ship it!"

Or maybe I've just had a bad week. It's Friday evening and time to test a beer or several.

Posted to Software Development by Keith Pitty