By LUKE MCGOVERN
Published: October 29, 2008
Legacy code is a term that has evolved over time. Most commonly it was used to describe code that was built for a particular environment and/or specific hardware that had to be carried through with future development as there was still a need for the functionality. More recently the term refers to old code that was written for different requirements. It can also mean code that was handed over from another developer.
The general impression is that legacy code has to be old. This however is far from the case and points to the true meaning of legacy code (in its modern incarnation). Coders are quick to call something legacy if the code is architecturally flawed and avoids possible best practises. The term seems to refer to a code base that is no longer being engineered and simply being continually patched.
It's a sad sight when a code base gets to the point where the design and the allowances for future features are no longer considered and it's all about "just getting it done". In some ways it can be fun to ride the wave and code in a near carefree fasion just to see how quickly you can code stuff. In some cases it can increase productivity through the roof because all the developers have finally stopped complaining and just concentrated on getting it done. The ride, of course, doesn't last forever and you'll want to make sure you're not going to be living with the legacy code much longer than you have to or you will find yourself at the end of the development tether where you find you can "codes no more!"
The main reason legacy code is so bad is that it is so complex that it becomes illogical to the mind and fragile for the system. Programmers need logic. It's all we have. It's what code is supposed to be. If it's taken away from us we tend to get a bit shirty.
You know you are working on legacy code if it's hard to add new features and it's even hard to fix broken features. Often you find yourself in catch-22 positions and find you have little wiggle room and you know deep down you are going to have to tear up the code to get things to work - the reason being - there are so many business rules that have been developed and undocumented that every time you touch the code you are going to kill something.
In web development especially, you will find that most new coders on a project will constantly complain about the code and most of time suggest that it be re-written. Sometimes this can be a valid suggestion but most of the time it's just best to just suck it up and feel you're brain expand as you attempt to wrap your mind around all the hidden business rules, hacks and endless ill-logic whereby you become one with the code and all pain just fades away.