Does not documenting code result in job security? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.