As someone who has spent an awful lot of time documenting *other* people's code over the last few years, I believe I can offer some insight as to how it gets that way.
IMHO, the big reasons for poor documentation tend to be either related to the self-interest of the developer, or insufficient time being allowed by management to create the documentation. On the self-interest front, we have:
- Job security: If it is apparent that replacing a developer is going to be costly due to nobody else knowing the tricks of the undocumented code, nobody is going to put their hand up to be the one doing the firing, as the resultant disaster from the replacement getting up to speed is probably going to be blamed on the one who did the firing.
- Artificial inflation of worth: If a developer knows the secrets of the code but their coworkers do not, they tend to look considerably more efficient and productive than their coworkers when working on that segment of code. This is so common that it's almost easier to list the cases where it doesn't happen, than where it does.
- Politics and currency: Knowledge of the code has value, and withholding that from others gives it value that can be used to buy favours from other people, or used to "punish" people who cross them.
- Lack of visibility: Poor commenting and inaccurate documentation is often only really noticed by people with the technical background to understand it. If the developer answers to a non-technical person, they can choose to get lazy about the things they don't strictly need themselves.
- Revenge: If the developer leaves, the next guy is going to have a lot of trouble getting up to speed. By withholding documentation, the developer can make sure the impact is greater, and is really felt.
- Hiding bodies: If the code is hideously broken, and the developer incompetent or inadequately resourced, having no documentation allows them to hide this for as long as possible whilst they look for a way to get out of the organisation, reputation intact. Let the next guy take the heat.
On the management side:
- Lack of understanding: Sometimes management doesn't understand that if documentation (and code cleanups) and forever withheld, the codebase will become an unmaintainable mess. Simple changes start to take forever, and complex changes never fully work due to the need to hack them in.
- No time: Sometimes documentation becomes a "work in the background" thing, where no time is really ever allocated for it, until some disaster strikes, and the same people cry "but where was the documentation". Writing documentation (eg. technical documents) takes time, not only from needing to refer to and test the code, but also to verify and proofread the whole thing. It never happens in magical zero-time.
- Job security: Similarly to the developer's trick, management can do this too. If they hold knowledge about how everything fits together, and it's not written anywhere, then it's going to be hard to replace the *manager*, for the same reasons.
- Artificial inflation of worth: Let's face it, the manager's manager is probably never going to really read any technical documentation- they're too far removed from it all. Who looks better: The manager who delivers work in eight months, or the one who does it in nine, with proper documentation?
- Short-term focus: If the driving factors are always the externally visible ones, and internal concerns such as code maintenance are always neglected (perhaps because the manager won't explain the necessity of this to the higher-ups), then documentation *will* be neglected. If the manager plans to move on in the medium term, they may not care if the project falls over in a heap after they leave- it's unlikely anyone will pin it on them, and it may not matter anyway.
And a last one that's in a class of its own: Inability. Not everyone can write documentation well.