Honor Your Legacy Code
Many of us groan when they have to deal with legacy code. Especially those among us who fancy themselves to be craftsmen or clean coders often complain about long convoluted classes and methods, no tests and a tangle of dependencies.
I wrote before that you should shy away from the temptation to rewrite a legacy project. Today I’ll go even further:
Be grateful for the code no matter how messy it is!
If you have to work with this piece of code it is a strong indication that it does something usefull.
Actually everything we do depends on legacy code.
Your operating system: legacy (yes even the nice fruity one)
Your IDE: full of legacy code
Your Continuous Integration system: mostly legacy
Your Application Server: nothing but legacy
So the next time you encounter legacy code: stop swearing. Relax. Think of all the things it does for you and your boss or customer. Thank the creators for this.
Then concentrate on the thing it doesn’t do or does wrongly and fix it in a nice and clean way.
How do you define legacy code? Code without tests (as Michael Feathers), code with unclear intent, or just “crappy” code?
Any of the definition works in this context and I had no specific definition in my mind, when I wrote this.
MarLo’s famous Calc_Pick routine is classic legacy code that has done complicated order calculations for billions of parts now and is nearly the same as when YOU left it in 2000. All new members of my team swear allegiance to this incredible (and mysterious) piece of code upon joining my Geek Squad.
I bow to this work of genius.