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.


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.

Leave a Reply