While what you write is true in a way, but saying "military or gov't produce exact specifications for something" may be interpreted by some people involved in s

While what you write is true in a way, but saying "military or gov't produce exact specifications for something" may be interpreted by some people involved in software development in the wrong way. I've worked on a couple DoD related projects long ago and they don't put out specifications as much as requirements. If anything, the requirements are annoying vague. They will ask for something like "a light truck that can carry at least 1 ton while overcoming vertical obstacles 1 meter high and climb 50% grades". Or "software to track and manage electrical usage of a base at the building and circuit level. It should includeoff-site historical data storage, an interface for reporting and the ability to transfer data with existing reporting systems." Obviously the real RFPs have a long, long set of requirements, often conflicting :-). Each vendor is responsible with coming up with their own approach to the stated problem, their own designs and all the rest. And while there is certainly far too much micro-management -- and a healthy does of mismanagement -- a naive read of the rules makes it clear that most of the bureaucratic rules were created with good intentions. That is, they were created to fix "bugs" in the procurement system, to reduce corruption, to try to reduce errors, etc. Sadly, as you implied, the mass of contract bidding rules is now literally inches thick when printed out (I know because I printed out one set of them from the GSA) and probably create more problems than it solves. Ah well, such is life.