[ten-seven]

We have a concept we call our "Bus Number." It's the number of people that know how to do what you do, or have been briefed on what you're doing, so that if you're run over by a bus, they can pick up what you're doing. It's a grim concept, but it highlights another point: what happens during the startup period should a key person fall ill, or die? Good documentation could save the shop and make sure your dream lives, at least for a while longer.

[mynameishere]

http://c2.com/cgi/wiki?TruckNumber

.............

Anyway, documentation is all well and good when it takes the form of a "how to". That seems to be what the author is getting at. But there's just nothing worse than reading or writing documentation that consists of proposed method signatures, object structures, or anything in any way related to UML.

[pchristensen]

He's referring to business process documentation, which is different than code documentation. Coding (or design in general) is different than operations and can't be documented as precisely. It's the difference between "Here's what I did" and "Here's what to do"

[keating]

I prefer to keep that number at ONE, so my co-founders have an incentive not to kill me.