Legacy System Seniors – The Lord vs The Reformer

Mission critical legacy systems tend to attract two flavors of Senior Developer: The Lord and The Reformer.  The Lord runs his team to ensure his usefulness to the company and his primacy in the developer hierarchy, while The Reformer focuses on rebuilding the team and business value.

If you are a manager taking on a new legacy team, or developer on a legacy system getting a new senior developer, the good news is that you will quickly be able to tell which group your senior falls into.  The difference is stark and telling within 3-6 months if you’re paying attention for these 5 major signs:

  1. Both The Lord and The Reformer may point to a piece of code and say “I’m the only one who can understand piece of code”.  The Lord will say it as a point of pride and evidence of his superiority. The reformer says it sadly knowing that if only the Senior Developer can understand the code, then code is bad, even if it works correctly.  Over time The Reformer will shrink the inscrutable parts of the codebase through refactoring and tests. The Lord will both proclaim that nothing can be done, and complain loudly and often, about being held back by the terrible state of the code.
  2. When a junior developer joins the team and asks about documentation, both may say “this is a legacy system and there is no documentation”.  The Lord will then suggest the new developer read the code to understand, and may even smirk and suggest that the new developer write some documentation during the journey to enlightenment.  The Reformer will point to the parts of the system that have been documented, discuss the best way to get familiar with the code and offer to write additional documentation as questions arise.  The Reformer expands documentation with every hire, The Lord will complain that adding people is taking away from his development time.
  3. The Lord instinctively knows that critical developers can’t be fired and works to increase the company’s dependency on him.  The Reformer knows that if you can’t be fired, you also can’t be promoted. The Reformer works to ensure he can step out of his current team at a moment’s notice so that he is available to step into a bigger role.  This sign is a little subtle, but consider your bus factor. If the Senior got hit by a bus, how long would it take the rest of the team to handle support? The time for Reformers is measured in days, Lords in weeks.
  4. The Lord believes that the system couldn’t possibly function without him and speaks of his overnight heroics as a point of pride.  The Reformer views anything that requires his presence as a mistake that needs correcting. The Lord will rarely fix the underlying issues that result in heroics, while The Reformer makes them a priority.  As a result The Lord will spend a steady amount of time dealing with production, while The Reformer quickly oversees a very calm environment.
  5. The Lord will take all of the new feature work “to ensure it is architected correctly” and leave all of the maintenance work to the junior developers on the team.  The Reformer will take all the maintenance work and teach the rest of the team how to build new features. The Lord’s team will have an ever increasing amount of maintenance, and production issues, while The Reformer’s team will see bugs and maintenance work drop dramatically.

The good news is that you’ll know very quickly which Senior you have on your team.

The bad news is that The Reformer won’t be around long.  By improving the system and the team The Reformer won’t be needed and you’ll soon lose him to a new disaster.  There is a silver lining, teams run by Reformers become attractive to other developers and you will have volunteers looking to join the new hot team.

The worst news though, is that The Lord isn’t going anywhere.  His antics will actively drive away developers and managing him is your problem.

One thought on “Legacy System Seniors – The Lord vs The Reformer

  1. Great post, there are many terms for each of these roles, but the key point is the tendency to horde knowledge or disseminate it. Knowledge share diminishes one individual contributors value to the business at large on the surface, but it also hinders growth, as you point out. The net effect is a stagnant code base with a continually decreasing support base for said application. IMO, a good lead will be the first person to admit they don’t know about a thing, and the last person to admit that they can’t do a thing.

Leave a Reply