- Yes, the name of this client has been changed to protect the guilty.
- No, this was not official
- Yes, there was a high Dilbert Index at this client
The point is that code becomes a legacy the moment it's written. But why is this so? And how can it be mitigated?
Michael Feathers introduced a novel definition of legacy code as "code without tests," in his Working Effectively with Legacy Code. But inheriting a large code base in a strange language without any author to consult is still scary, even if it is accompanied by a regression test suite. Here's a thought experiment. This same financial institution (see above) found a portion of crucial code in production which was written in assembler, somewhere between 3 and 5 decades ago. There was no source code. Would this have been eliminated as a problem if only a test suite had been available?
The problem with code is that it is an enormously mental activity. My copy of Coders at Work is loaned out, so I can't quote the source, but one of the interviewees claimed that what made a top coder was the ability to hold the entire program in ones' head at one time. This is a huge achievement. And it's difficult. One phone-call can destroy it.
But the further problem is that when you do have this Wondrous Vision everything is crystal clear about how your program works and why you did it in this particular way and how all the tricks, tactics, and techniques fit together to do it elegantly.
But this vision is a perishable good!
And, therein lies the rub. When the vision is present, it is beyond pointless to write it down. Plus, you're under delivery pressure and documentation/explanation is not the primary deliverable. But the vision decays: geometrically. Inexorably. Heck, we said before that a mere phone call can destroy it! But time eventually kills it entirely and all those explanations that were so clear become murky, unclear.
Almost every programmer has experienced this. You go into some code you wrote last year and wonder, "why did I do that in that way?" And this may take quite some time to resolve.
This blog is too long already, so discussing possible mitigations will have to await the future. In the meantime, ...
I Remain,
TheHackerCIO
With code as with everything else in life, we make decisions in the face of uncertainty. There are lots of decisions to be made and each has lots of tradeoffs whose merits can not be fully appreciated until Other Things happen.
ReplyDeleteThings like
- doing the hack enabled you to ship, hit your quarterly numbers and prevent a wave of layoffs
- doing the hack resulted in a maintenance headache for the guy who needed to extend a feature that didn't exist when you did the hack
- doing the hack resulted in no problems over the entire life of the project.
Any of these is a possible outcome. When you need decide to do the hack or opt for a more fully engineered solution, you are guessing which one is most likely. That, much more than our abilty to point out "not good enough" is what we get paid to do.
You mention crutial code in assembly that no one understood. When I found out that we had a similar situation on a new product we shipped 10 years ago, I was similarly concerned. In the next 5 years of maintenance, we did lots of enhancements, lots of fixes and the product seemed well recieved. The assembly routine never needed touching. It could easily have been different.