Possible Duplicate:
Should you write good documentation and clean code to increase the “Bus Factor”?

I often ask young programmers why they are not documenting their code. Their responses, perhaps jokingly, frequently include "job security." I hear this from experienced professionals, too. And not just in programming; network engineers and system administrators widely subscribe to this belief.

Can you really ensure job security by holding the details of your work in your head rather than on paper (or in files)? What's your experience?

  • 6
    Nobody is indispensable. Anybody who thinks they are needs to eat a big slice of humble pie.
    – maple_shaft
    Apr 2, 2012 at 19:58
  • 4
    "Fire the indispensable programmer" - my 2nd semester computer science professor. Apr 2, 2012 at 20:25
  • I would not have guessed from title of the "bus factor" question that it was a duplicate. The question search engine here didn't offer it as a suggestion, either. Apr 2, 2012 at 21:57
  • “The cemeteries of the world are full of indispensable men.” - Charles de Gaulle.
    – user1249
    Apr 2, 2012 at 23:13

7 Answers 7


Any responsible manager will dismiss an employee who has become indispensible. The reason is the longer they are there, the bigger the damage when they leave.

For an employees point of view, this kind of "Job security" is not wise - management cannot promote someone who is indispensiable, they cannot give them the new projects. You will be stuck on the same ground hog day for the rest of you life. Might not sound to bad at age 20, but 20 years later doing the same thing the same way with a manager old enough to be you son .... So you decide to leave, but can't find a job because of you reference checks, and mostly will never know why.... Worst case, probably, implausable - certainly not.

Edit / Clarification There are many ways to dismiss someone in this situation - a sideways or even downward move may be appropriate, however if the person is an empire builder they usually just build another empire, and often will not go willingly (once they see power being taken away). If they just "fell" into being irreplaceable, they will usually be the first person to identify the issue and will willing participate in the solution, that is not what this question is about. If the entire organizations vitality or even survival depends on not being able to dismiss an individual, then it will cost less to do it sooner rather than later.

There are very few Steve Job's in this world, and the guy that is building his empire is, on balance, very unlikely to be one of them. I have often observed "irreplaceable" people being replaced, usually at a much smaller cost than anyone imagined.

  • 4
    I would up-vote this answer for the second paragraph. I would down-vote this answer for the first paragraph. Perhaps a manager would dismiss someone who has become indispensable, but I'd hardly call that person 'responsible'. If a person is indispensable, then by definition they are absolutely essential to the success of the project. Dismissing them would be akin to curing the disease by killing the patient. Apr 2, 2012 at 20:11
  • @DanielPratt depends, you can boot a programmer that's "indispensible" on smaller/replaceable projects. Just because your code sucks doesn't mean you can't be replaced.
    – Ben Brocka
    Apr 2, 2012 at 20:16
  • @Rarity Since we are all programmers here, I will embrace my inner pedant: If a programmer is only "indispensible" with respect to projects that are themselves "replaceable", then he or she really isn't "indispensible" at all. Apr 2, 2012 at 20:24
  • @Daniel: I have been in this situation (As an observer). One lost (fairly major) project would have been cheaper and easier for everyone in the long run than an entire organization being held over a barrel for years.
    – mattnz
    Apr 2, 2012 at 22:53
  • @mattnz OK, last retort, then I'll drop it. Your recent edit makes even less sense to me. If the survival of an org depends on one individual, then getting rid of them will cause the org to fail. What higher cost is there? At least if you keep them around for a while, you have a chance to change the situation. Apr 3, 2012 at 0:06

I have not experienced this firsthand, but I think it's a very silly mindset from the get-go.

Why become indispensable by being bad at your job when you can become indispensable by being good at your job?

As a young programmer, I will tell you that I try hard to document my code at least moderately, but this is the sort of thing where habit will play a much bigger role than intention. When I first started programming, I didn't have a solid appreciation of the value of commenting code. As I got into more programming classes and deadlines got shorter while projects got harder, I didn't always comment my code because I didn't always have time. I hadn't gotten into the habit of documenting as I wrote, so I would often document as an afterthought.

I believe many people are in a place like this: if commenting code isn't a deliberate practice from day one, it takes more work to ingrain it, and many people probably never put forth the effort to make that happen. However, I never willfully keep comments out of my code. If I have time and remember that it needs doing, I believe it should be done.


As much as we all like to believe otherwise, information hoarding can work. At best it's a risky strategy, since clearly information hoarding is inherently selfish, and people will probably get angry if they catch you.

As an aside, you might be wondering "how could anyone possibly not get caught?" However, I've witnessed people that hoard information from the technical staff but pretend to management that they are cooperating. But all information sharing is in fact deliberately incomprehensible or false.

This doesn't fool the technical staff for long, but it does make it hard to prove, and anyone in position to information hoard has probably been around longer and therefore has more trust from management. Especially since they are in position to create a story of themselves heroically saving project after project from successive waves of programmers that can never seem to get the system to work right.

Information hoarding is especially effective if the information being hoarded includes a lot of the actual system requirements, since technical employees can eventually figure out even the most obscure code given enough time. But doing all that plus determining the requirements takes even longer, and will be almost impossible to do without it getting back to the information hoarder.

Obviously, it requires bad management to let such a situation to develop, and to let it continue, but even in this day and age there are still a very small number of companies with a single department or two that in their very worst moments allow occasional bad management.

Interestingly, for the information hoarder life as a miser is often pretty tough. They probably can't improve their skill set because they are busy being essential to whatever their hoarded information pertains to. Soon they can't change jobs because that's all they really know how to do. And they have to live in fear of new management with sense enough to see what's going on and the guts to pay the short term costs of fixing the problem.

So, I wouldn't recommend it to anyone who isn't unethical and desperate. But under some circumstances it can provide more job security then not doing it. But less career security.


I doubt it. If you're writing bad code without comments, you're a bad programmer. That doesn't sound like good job protection... You probably won't be able to hide it from all technical staff on your team. Eventually someone will call you out to management for not being a very good developer. You are more likely to have good job protection if you earn a reputation for being a great developer who writes good code. This is much more likely to protect your job, since finding good developers is much harder than getting someone to understand poorly written code.

In any case, I don't think developers really need to worry about job security today. it's one of the largest growing job markets, so it's not like you need to hold on for dear life to one job. If you lose your job for whatever reason, turn around and there are plenty of other job opportunities.

  • 1
    Plenty of job opportunities, but many of them offering sub-par salary, tools and working environment quality. Apr 2, 2012 at 20:06
  • 3
    But also plenty that are probably even better than your current job.
    – Oleksi
    Apr 2, 2012 at 20:07

I think that young people don't document the code because they came from college (or similar IT educational system) doind only small projects alone, so documentation is not needed.

Most experient programmers can be these young people older or just people that works on the same single project for years, so it knows all the aspects of the project and don't care about the others because he is the senior/mastermind of that project.

Not documenting the code for job secutiry only will hold your position if is a small or old company with old mind.


A good number of companies operate under "tribal knowledge" when it comes to internal projects. People who've been around a while accumulate knowledge and are often reluctant to let it out to new members of the tribe. Some will cite security concerns ("Our business rules are on a need-to-know basis and you don't need to know them for your project"). Some will answer in acronyms terms that only someone with years of experience in the company will know ("You need to use the unified TXD interface, not the TXM interface, to get the UIO properties to find the JV standard values. From there you need to...").

Sometimes this is by design, with people defending their knowledge and superiority on the team. Sometimes it's just how the company's software development culture evolved. The first kind can be a very toxic work environment and is common in companies that practice misguided cutthroat management techniques like "rank and yank". The second can happen due to a inconsistant or poor management and tends to be more common in smaller companies/teams that grew fast with few controls.

All in all, it's not a good work environment and a good programmer will take steps to prevent it from happening in their organization. Yes, it can result in job security for some but it's at a heavy cost to the company and to team members.


Definitely not. They wouldn't last very long on my team, especially if I was their superior.

Documenting work is valuable for the company in general so I cannot see how this would be allowed to continue unless the company itself does not realize the value being lost by not having proper documentation in place.

I'll be damned if I can remember every little detail about the code that I have written over the past several years, so if I haven't documented anything I will eventually put myself out of work.

Not the answer you're looking for? Browse other questions tagged or ask your own question.