#31-Legacy Code and Magic Buttons Part 1

What is the best way to deal with the fact that most organizations have a high degree of vulnerability to the quality (or lack thereof) of the legacy systems they depend upon?  This week I'll discuss a thought experiment that helps us to understand this conundrum, and next week I'll show you what to do about it.

Transcript

Legacy code is often a major impediment to organizations that develop and depend on automated systems, which these days is pretty much everyone.

The problem with legacy code is that it was usually designed and developed as a time when computer hardware was extremely expensive, and limited in capability, while software developers and their time were relatively cheap.  When I was a young developer, I made little more than minimum wage and I was happy to get that: there was not enough work for all of us.  Computer processing time was limited, things like memory and diskspace were orders of magnitude more expensive, and there was nothing like a terabyte storage device anywhere on earth.

So, if code could be written that made it easy on the computer but might be difficult to maintain by developers, that was usually the priority.

Today this equation is the complete reverse.  Computer hardware is cheap, and extremely capable with lightning-fast processors and massive amounts of memory.  I personally own a terabyte thumb drive I got for $40 on Amazon! But software developers are much more expensive and sought-after.  Their time is often the most expensive part of the process.

Legacy code also rarely has tests, or at least the tests it has are very poor and slow running by today's standards.  If we could, we would stop and refactor these systems to make them more testable and therefore easier/more efficient to maintain, but this is almost never a realistic option. So, what should we do?

Consider this thought experiment:

Imagine there are two magic buttons before you, and you may only press one of them.  We'll call them A and B.  If you press button A, then suddenly and with no effort you will have fast, granular tests that cover 90% of your legacy code.  If you press B, you will get the same result, but only with 75% of the code being protected by tests.

However, there is another difference.  If you press A, leaving 10% of your code uncovered, you will not know where that code is in the system.  You'll only know that it is 10%... somewhere.  If you press B, the 25% of your code that is not covered will be clear and obvious to you.  You'll know exactly what code is covered and what code is not.

Which would you press?  If you say A, then you might want to reconsider.  First of all, as I pointed out in my very first agile tip, code coverage does not necessarily mean what we think it does (if you missed that one, it's now a podcast that can be listened to at any time).  But even if it is legitimate coverage there is still another issue involved.

If you consider risk mitigation to be important to the health of your business, then you'll press B every time because knowing where you are and are not vulnerable is essential to achieving that end. It will also help you to predict what changes will cost, as changing uncovered code will be a much slower process. 

The problem, of course, is that magic buttons do not exist, and nothing can be achieved without cost. That said, there is a way to get the effect of button B with controllable costs.  I'll explain how next week.