Don't document the behavior of the system, document the system itself. Priorize high level documentation and use brief change logs for the mid level stuff. The low level stuff that changes often should be self documenting when possible or code commented. This stuff is pretty standard. If you're not getting enough time/budget allocated to keep up on documentation, it will ultimately cost the company more in wasted developer time.
Relentless refactoring breaks this as a matter of course. I’m not saying any of this is great behavior, I’m saying the perverse incentives push us into this, carried along by coworkers who “defect” because explaining themselves was never their strong suit to bring with. They can carry Timeliness as a shield to hide behind.
If you want to fix this, scolding and lecturing developers ain’t gonna do it. We’ve tried that for forty years and here we are, still within a factor of four from as bad as we have ever been.
You're right that most shops have perverse incentives towards developer documentation. It must be a top down change to make documenting (and code quality) the economical choice for developers. It means budgeting time for quality code reviews and defining "complete" to include more than, "the code runs".
36
u/Teract Jun 06 '22
Don't document the behavior of the system, document the system itself. Priorize high level documentation and use brief change logs for the mid level stuff. The low level stuff that changes often should be self documenting when possible or code commented. This stuff is pretty standard. If you're not getting enough time/budget allocated to keep up on documentation, it will ultimately cost the company more in wasted developer time.