This is absolutely wrong. Documentation should describe the intent of the development organization, not its current state. Sure... if you're building a web si

This is absolutely wrong. Documentation should describe the intent of the development organization, not its current state. Sure... if you're building a web site, the decision to change the background color to light yellow instead of white probably doesn't need a design review. But if you're building a banking back-end, you probably want to list out a few requirements that aren't going to change (like "overdrafts should be impossible", "you should support multiple, simultaneous transactions", etc.) And when you find that your requirements are difficult to ALL implement, that's a finding. It means there's more to the problem domain than you anticipated and you may need to go back and think about it again. Documentation is not hassle foisted upon coders by idiot architects. It is (when done well) the artifact resulting from the design process. I sounds like the OP has a history of working for dysfunctional software development organizations.