Old Code: Don’t call it legacy, stale, or deprecated.

While working on an Analytics platform, I approached my manager about some of the older pieces of analytics. A section of code known for its complications and quirks – written by people no longer present at the company. I had been tasked with isolating this rather large stack into isolation – and it needed a name. I suggested Legacy, and was surprised by how quickly that idea was turned down. He explained his reason to me – but now I get ahead of myself.

A phrase often heard and acknowledged throughout development is that, “naming is hard”.  He we are a collective lot of somewhat intelligent people, and yet we stumble at naming things. Maybe this is because “Engineers can be weird“. Maybe Shakespeare has been misrepresented by one of his characters on the smell of stink-buds. Maybe naming is hard, just because of what it represents. Which still leaves the question, “Why can’t I call it legacy?”  Without further ado, here are different stages of ‘legacy’ and some ideas for names.

Stable: not likely to change or fail; firmly established. – Oxford Dictionary

Replacement plan


You’ve identified old code. It’s massive, it’s unwieldy. It’s still your main core code, but it doesn’t change much anymore. I’ve seen code at this point referred to as stale – but try to avoid that. Instead, call it stable – because that’s what it is. Calling something stale has strong negative implications. Now, inside your development group – you’ll know what’s wrong with the code from a technical perspective. And calling it stale implies those ‘wrong’ things are not getting cleaned up. But let’s say that term spills out of engineering. Will this I instill business wide confidence in development engineers? No. It will most likely invalidate developers because they produce stale things. Calling it stable will show that things can be built to last.

Deprecated: (chiefly of a software feature) be usable but regarded as obsolete and best avoided, typically due to having been superseded.  – Oxford Dictionary


That old code that has been sitting around? “Old Busted”, we’re going to use the “New hotness”. Unfortunately – this is a common point where “Old Busted” is referred to as deprecated. This is where the first portion of the definition of deprecated is used. What is really needed before we can call it deprecated is the actual replacement. So again, keep calling it stable code. This will bolster morale for anyone still working on it – whereas calling it deprecated will cause developers to head for the hills. Calling it legacy at this point also has the same effect on developers. Who wants to care about something going away?  Well, the people keeping track of the money do. You want everyone to care about the old code – until the point it is truly gone.

In progress

“Old Busted” is shrinking. It’s almost getting to a manageable place – there’s still a dev or two working on it – One might think now is the perfect time to call it legacy code. But it isn’t. In fact – don’t call it legacy until it is gone. At this point, there are areas that can truly be called deprecated. The “New Hotness” has in fact replaced the old in a shiny new ways. But it likely hasn’t covered everything at this point. Continue to refrain from using negative connotation description of the stable code.

Completed new work

The new code is dev complete. A lot of it is out in production – there might be a few dangling deploys. The A/B test is still in progress – but the new is clearly taking out the old. Now is a time to party! Call the old code deprecated. Refer to it as legacy – revel in the victory. Then summarily delete the code base and forget it ever existed. It’s what we do. It turns out, pretty much anyone can write a line of code – but removing old lines of code that are no longer relevant. Or even the ability to identify them. That is true skill.


It isn’t the end of the world if you call something ‘dead’ before it’s dead. Everyone will go along with it. But, do you really want to make good devs suffer for maintaining the bottom line? Or decrease the already small amount of trust business folks have for devs? (Maybe a future article about smart, untreatable, developers?). In the end, the words we use to communicate convey context. Personally – I’ll take a positive context spin over a negative one every day.


Dev Profile: Maintenance Master


If you’ve ever worked in a service industry, you’ll have noticed that there are many people that just do their job. They go to work, do what they are supposed to, collect their paycheck, and punch out at the end of the day. They fill a role, and they do well at it. They stay out of the spotlight – their ‘off’ time being their fulfilment, and the job being an ends to a means. The same holds true in the Software Development environment.

Software stacks are large these days. Well, at some startups the code base is still growing, but even their, the open source code being referenced is quite large. Now, it’s great when a developer / architect can build and design these larger complicated systems. But as time goes on – new things don’t need to be built out so much as in the past. Sure, things like GDPR can wreak havoc on websites, but for the most part, code bases are pretty stable.

Ideal Scenario

An example of where a Maintenance Master is most suitable: Imagine a stable codebase which doesn’t need to be completely re-written. It needs to be maintained. Minor to Major bugfixes, improvements, business logic changes – these are common maintenance items. This type of work can be well planned out, well tested, and scheduled. Which makes it the ideal scenario for Maintenance Masters.


Being able to keep a code base alive and relevant is no small task. Knowing the reason for business logic implementations. Having a history of decisions. Doing all this without checking the Repository history or checking the resolved tickets list is a huge asset. In addition to this, they are great at sticking on a problem until it is eventually resolved. They’ll guard their area of expertise and are predictable about the deadlines they can meet. Sometimes they’ll explore new ideas or concepts – but they are largely happy with the status quo. They are able to churn out a lot of code – but it’s going to be the same code style repeated in every scenario.

To summarize:

  • Consistent
  • Dependable
  • Thorough
  • Content
  • Knowledge Stores
  • Persistent
  • Produce a lot of code


Being able to stay on a single project or code area for a long amount of time might be great – but it is countered by being unable to see larger solutions or newer approaches that can clean up the code. For example – the DevOps movement has put a huge dent in the abilities of maintainers. Now, their entire process must be revamped. This in turn causes maintainers to become disenchanted with their code or their company – and often will result in their departure for a more stable opportunity.

Not being a part of the huge ‘go getter’ mindset, maintainers don’t typically go way above and beyond the job description. They aren’t typically looking for a promotion and often watch others pass them by. They’ll sometimes get stuck maintaining a failed piece of code without realizing a refactor would be more useful in the long run.

They also sometime lack in their communication skills. They know their job – they expect you know yours, and they don’t anticipate communicating what they are doing outside of what the process makes them communicate.

Managing a Maintainer

There are some obvious do’s and don’t’s when managing or leading a maintainer.


  1. Keep their work planned and organized
  2. Give them an area to own
  3. Give them some autonomy
  4. Keep their environment stable
  5. Provide early notice for large changes conceived for their area
  6. Use them to train new people


  1. Haptic switching of their projects
  2. Expect new ideas
  3. Promote them to architect positions
  4. Use them to interview
  5. Push them outside of their comfort zone.


Maintenance Masters are an excellent piece of a development team. They will keep the lights on and things stable. They won’t push much of a changing agenda – but they will get things done. If you blame a code base, you’ll find their name dispersed through a file – not as an originator, but as an editor. There is absolutely nothing wrong with being a maintainer – however – if you are one, and you want to move into management or leadership, you’ll need to step out of your comfort zone.

Dev Profile: Emergency Response Hero

Someone just noticed Production fell over. Ops is looking into the situation. Devs are looking into the situation. Dev Managers are hovering – the situation is tense. In terms of the Restaraunt Analogy – Someone sent the wrong dish to a customer, and the kitchen is trying to recover. Enter the Emergency Response Hero (EMH)! With one look at the problem – he asks a few questions – fly’s through recent commits, check configs, and quickly ascertains where the problem is. Without telling anyone – he jumps towards the fix – and lets everyone know, “Hey, I’ve got it. Here’s the problem. Here’s a fix!” The fix goes out and all is well with the world. Until the next emergency. Everyone lauds the hero with accolades! …and the person responsible for the initial issue hangs their head in shame.

In the real world – as opposed to the world inside a development shop – Emergency response heros save lives every day. Natural disasters and accidents are common. We live in a chaotic universe. We need and appreciate our Emergency personnel for good reason. But what about a controlled environment? It’s a great thing to have someone capable to recover quickly from an issue at hand. However, there comes a point where relying on emergency personnel all the time is a problem.

Do you have someone in your team that wear’s a fireman’s hat (or equivalent) to work?
Do you have someone unable to complete and planned work as they are always saving the day?
Do you know a dev that gets more accolades then anyone else – but not for innovation but rather fixing things?
If you answered yes to any of these, you might be working with an EMH.

Working with an EMH can be rewarding for a dev manager. But, at the same time, they can demoralize the crew. Some will respect his accomplishments. Others will be ambivalent – and others, hard workers that don’t get accolades, will be jealous. When people become jealous, they become demoralized. Then productivity falters. But how to avoid this? Personally, I recommend better Automated Testing. A highly visible EMH is a strong indicator that Automation is not doing its job. Try to get ahead of this curve before it is too late. EMH’s get burned out too.