People joke about militaries writing docs about the exact number of turns each screw can take, but a-10 are still airworthy and the last one was built in the 80

People joke about militaries writing docs about the exact number of turns each screw can take, but a-10 are still airworthy and the last one was built in the 80s Quips aside, software life expectancy matters, so total documentation approach is not something that works for everything. But if your software has generations of developers, maybe it's worth thinking about it. That or a total rewrite every skip generation. I can see both working, and maybe total rewrites are a better approach in a world of ever changing requirents. Thing is, documentation is great to capture static knowledge, and a evolving software is not static by any means If I had to pick and choose, I'd say written requirements with change management for every domain object APIs within the software object model, and anarchy underneath. The code conforms to the requirements, and not the documentation conforms to the code, so to say. Contract driven, in a way, but only where it's relevant.