[Quekid5]

> The popular answer was that projects change too fast and he doesn not have time to maintain docs.

I sort of agree with this, but rather from the perspective that often the effort required to maintain documentation isn't in proportion to the payoff.

Naturally details differ among projects, but I find that the 20-80 rule applies to documentation, i.e. that 20% of the documentation provides 80% of the value. I find that focusing on stable architecture/properties of the system is a good approximation to the 'important' 20%.

If the system also has any especially tricky parts (e.g. a transaction coordinator) warrants documentation, but that also probably falls under the 'not subject to rapid change' 20%.

I'm assuming project internal documentation here. If you're documenting things for customers, then you'll want to document everything very thoroughly, but one would hope that people figure that out eventually when support tickets keep coming in...

EDIT: Clearer phrasing