The Hostage Taker

Developer who has written a piece of mission-critical software, and refuses to let any other developer work on it so that they may remain indispensable.

Problem

To anyone with financial responsibilities, job security is important. Additionally, to anyone wishing to have low job stress, working with the familiar is far easier than working with the unfamiliar. At the intersection of these two desires is The Hostage Taker, a developer who has written and exclusively owns a critical piece of software, and refuses to work on anything else.

The Hostage Taker is normally a poor software engineer, and ironically that deficiency translates into a major asset: Their software is typically incomprehensible to anyone but them, and therefore other developers are intimidated to wade into the quagmire that is their code for fear of doing more harm than good. All new work for the mission-critical system must therefore go to The Hostage Taker, thus continuing the vicious cycle.

The Hostage Taker is routinely defensive and confrontational, and are absolutely closed off to critique or collaboration regarding their codebase. If truly backed into a corner, they will threaten to leave, and because no other developer wishes to own their poorly designed and woefully implemented piece of software, their bluff is rarely called. This can place them as a choke point in the project, as the entire fate of the project rests on their desire and ability to deliver.

Solution

As dangerous as The Hostage Taker is, the solution is straightforward: Give two or more developers responsibility for The Hostage Taker’s part of the system, and assign The Hostage Taker to a new part of system. There will be a period of time of no productivity as the new developers attempt to understand and redesign the code that was taken hostage, but once that period is over, The Hostage Taker will have been fully neutralized and no longer pose a problem.

3 thoughts on “The Hostage Taker

  1. I dealt with this, and unfortunately, I quit because management didn’t understand the situation. Not too long prior to that, another senior engineer (very talented) left because he was dealing with it on another team. This is why it’s important to have good engineering managers. I learned valuable lessons, nonetheless. I found that situations like this are common when there aren’t any technical leaders who are close to the project.

  2. I think that the solution should be – fire the hostage taker on sight! The project can not preform if one team member is busy in “job security driven development”. As a manager I tried to ask other developers the responsibility of the hostage taker’s features, and they whole feature had to be completely rewritten. Then the developer decided to turn into “The Incompetent”.

  3. I agree with Henry, fire the hostage taker on sight. A good developer or two should relish the task of cleaning up the mess.

Leave a Reply