The Hostage Taker

Difficult Software 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.


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.


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.

8 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.

  4. I was once a hostage taker, but my skill level is very high, it’s harder to obfuscate codes than refactoring it to make it understandable.

    A badly written code can be comprehensible to a low-skilled developer for they have affinity to spaghetti coding.

    I didn’t start as a hostage taker, but the situation requires it such as High Politics / Toxic Workplace / Bad Boss

    So maybe if there’s a hostage taker, you should look for the rootcause.

    it was a financial system, one wrong code and kaboom

    it was fun seeing my bad boss can’t do anything even when I try a badass attitude. I even shouted at the workplace psychopaths, and tried to escalate me to the bad boss, and he can’t do anything.

  5. Oh God, I think I might be this developer type. I like to think my code is clean and compact, but I’m now worried I might just be an asshole.

  6. Sometimes you’re given a piece of critical code to implement in an impossibly short amount of time that you code it with total disregard for readability or the future just to meet the deadline and ungate the project only to be looked at as the Hostage Taker at the end.

  7. There’s a flip side to this – being dragged back from your new role to maintain a codebase the other developers don’t want to deal with. When the code is holding you hostage…

Add your thoughts