Creating Tomorrow's Legacy Code Today

"Creating Tomorrow's Legacy Code Today" was the humorous motto of a group I worked with at a major financial institution, Feral Hangman. 

• 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

A Dilbert Index is a way of determining the level of pathology found in a company. The higher the number of posted Dilbert cartoons, the greater the likelihood that this is an unheard message to the management. Or a protest.

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