It’s absurd when Mr. Lamport writes that developers don’t think beforehand about what to code and how to code it. Of course they do, I do at least. However, writing a detailed spec upfront will not ensure that software will do what it needs to do or that it does that stably. Not at all!<p>A simple piece of code can already amount to more complexity then a skyscraper. I think that most developers can agree that even when meticulously thinking upfront about what to make and how it should function, when a system is actually coded, new, unforeseen situations arise, always. This is without any exception. This simply arises from the fact that software systems become too complex for us to oversee fast. Especially how processing by these systems evolve over time is difficult to grasp.<p>Only in special cases you want to do some sort of formal specification to proof that something works, e.g. in the case of an algorithm. In all the other 99% of the cases writing good software is mostly about iterating and communicating <i></i>a lot<i></i>, with co-developers and stakeholders: In each small iteration we should think, discuss, code and assess.<p>Last, I do think that at least <i></i>after<i></i> the code has stabilized its functions/classes/methods/APIs needs to be documented such that it becomes easier for developers to fix, change or extend a system in the future.
...<p>Its a cost-demand thing. Software can (and sometimes is) built like we build, say, a skyscraper. The problem is that most people don't want to pay the same price for software as they would for a skyscraper. Mission-critical software is built more similarly to how a house is built than an iphone app. The price difference is also much much higher to match.
A must read: <a href="http://www.tablexi.com/blog/2013/01/why-building-software-is-not-like-building-a-house/developers/" rel="nofollow">http://www.tablexi.com/blog/2013/01/why-building-software-is...</a>