>"Not gonna happen. Why? Because: http://www.commitstrip.com/en/2016/08/25/a-very-comprehensiv..." http://www.commitstrip.com/en/2016/08/25/a-very-comprehensiv.

>"Not gonna happen. Why? Because: http://www.commitstrip.com/en/2016/08/25/a-very-comprehensiv..." http://www.commitstrip.com/en/2016/08/25/a-very-comprehensiv... That's a misunderstanding. Most specs aren't fully fleshed out code, they're the bare bones of describing what something needs to do. Think of it as if you're designing electronics out of integrated circuits. You can design a schematic just by knowing the inputs and outputs that the integrated circuits need to provide. The actual implementation of the integrated circuits is abstracted away. It's the same with the relationship with specs and code. Specs are meant to be at a higher abstraction level than the code they describe. You can use code to write specs (and there are advantages to doing so), but the idea with the specs is to define something which is universally true, rather than get into the detail of the work done to meet this specification. An obvious example of this is design by contract: https://www.eiffel.com/values/design-by-contract/introduction/ https://www.eiffel.com/values/design-by-contract/introductio... Whilst code contracts aren't necessary in all languages (this is a good starting point for looking into why: http://blog.ploeh.dk/2016/02/10/types-properties-software-designing-with-types/ http://blog.ploeh.dk/2016/02/10/types-properties-software-de... ), I believe they do offer benefits to software written in most imperative-style languages.