Re:Maintaining code quality when nobody cares
by jacquesm on Tuesday February 13, 2018 @12:03PM
(#16368688)
I've worked on old but very well maintained code that could easily go another two decades or more. Probably the original writers have long departed this world. But what they put together was put together with either incredible forethought or impeccably kept up-to-date. It was hard to tell which because this stuff was built before the age of version control, which gives you a bit of an idea how old it was. I would consider that 'mature' code, but not necessarily legacy.
Legacy code to me is code that has become hard or even impossible to maintain. Code that people avoid working on, not because it works, but because they are afraid of it.
Sure there are still lessons to be learned from such code, and you will learn those lessons the hard way if you have the temerity to mess with it. But every now and then someone is tasked with fixing a bug or adding a feature that can no longer be avoided and the send-offs are comparable to talking for the last time to people that are about to descend into a mine or something to that effect. Everybody knows there is a good chance we won't be seeing them again for the near future, if the axe of demotivation doesn't cull them from our ranks.
"Back in my day", legacy systems were admired! I mean, heck, they were still there because some team(s) were using them every day, more often than not, they were there because they made money.
As one famous software engineer once said, "'Legacy code' often differs from its suggested alternative by actually working and scaling."
NASA was reusing code written from the 70's all the way up to 2011! Surely there is something in this wonderful land of legacy code that is worth saving? Or how about our operating systems? Full of wonderfully working legacy software that might just need a touch of love, rather than the usual thrashing of "how stupid those other devs were" and a total rewrite, which is what usually happens sadly.
In any case, I think another poster may have touched on it, I think we as engineers should try to refrain from flippantly labeling anything that is essentially "old" (where "old" might be 6 months, 2 years, or 10 depending on the organization) as the pejorative form of "legacy software", and just call it what it is -- bad software, some of which may also be legacy to your organization. But the conflation of the two terms is not helpful and adding to the confusion.