A Difficult Software Developer whose only capability is the maintenance of legacy software, and therefore is incapable of taking on new work.
- Can mutate into: “The Hostage Taker” or ”The Soldier” Difficult Developer
- Dangerous when coupled with: “The Artist” Difficult Designer
- Likelihood of fixing: None
- Danger to project: None
Problem
When a developer first joins a company, they tend to be full of fire and passion as they attempt to prove themselves to their new employer. Overtime, however, that passion is often replaced with complacency, as they believe their tenure with the company has granted them certain privileges. The main entitlement they believe they have is to continue to maintain the systems they have built, which means they are unwilling to take on work in other parts of the system.
The issue with The Legacy Maintainer is a question of scale: they are simply not a part of the resource pool you can pull from for doing new work. At that point, it becomes a question if you can afford to keep them on staff, which itself comes down to if you can get other developers to take over their legacy maintenance tasks. It is typically difficult to convince other developers to do this for two reasons:
- Legacy software tends to be badly written, and therefore difficult to work in.
- Maintenance is a dead-end career path, as you are not doing anything new or innovative that may get you recognized.
This is why The Legacy Maintainers end up being with the company for a very long time. Often, they have been with the company since its inception, and were the authors of the software upon which the company was built. As the company grew, however, they did not get promoted into management, or attempt to learn new skills or new parts of the system, leaving them firmly entrenched in the only software they know.
Solution
The Legacy Maintainer does not really pose a problem provided you understand that they are not a resource for new project work. At most, they should be asked to fix bugs and implement small feature enhancements. The only problem arises is if they refuse to let anyone else learn their part of the system (see “The Hostage Taker” Developer).
There is no fixing The Legacy Maintainer, as they have no desire to be fixed. They have the same mentality about software development as does a factory worker: they want to do the same thing day in day out for their entire career and then retire. That attitude is not something that can be broken, as it is ingrained in who they are.
One of the ways this attitude can change is if they experience a life event (getting married, having a child, buying a house, etc.) which requires that they make more money, and they realize that maintaining legacy software is no path to promotion. Unfortunately, this is something you have no control over.
One risk I have seen in practice is that Legacy Maintainers demotivate newer team members by not seeing the pile of bad code they have accrued over the years.
They become emotinally attached to the system they’ve created and don’t want to simplify and don’t want to remove modules.
It is hard to criticize anything when a Legacy Maintainer always has good arguments combined with strong, informal office power:
– We have always done it this way.
– We invested a lot of effort into this.
– There was a good reason why I wrote it that way 5 years ago.
– It is too hard to change now.
– I’m not familiar with your style and familiarity is the core of maintainability.
This is a slightly diffent problem from “Hostage Taker” as there are no bad intentions.
It is an astute observation that the key difference between “The Legacy Maintainer” and “The Hostage Taker” is intention. The Legacy Maintainer is stuck in that role for one reason or another, The Hostage taker sticks themselves in that role to make sure that they can’t be fired.
To me, an interesting point is what impact a (potential) event to the legacy software’s lifecycle has to the legacy maintainer.
– Are they willing to participate in projects that aim to move all or some functionality to new software?
– How do they react if they know or think that the software might be discontinued soon?
– How do they react if substantial feature enhancements are planned to introduce to the software?
> One of the ways this attitude can change is if they experience a life event (getting married, having a child, buying a house, etc.) which requires that they make more money, and they realize that maintaining legacy software is no path to promotion. Unfortunately, this is something you have no control over.
Or do I?