“If we do not start with a specification, every line of code we write is a patch.”
Leslie Lamport’s wisdom deserves a wider audience in the age of hackathons. Marketing hype often makes software development sound like a form of speed chess played by savants. Personally, I find speed chess developers are more likely doomed to replay the same losing game over and over again in a vain attempt to stamp out all the bugs. No wonder we like to recruit programmers young and willing to spend soul-crushing hours fixing the same mistakes over and over again.
Who Builds a House without Drawing Blueprints? By Leslie Lamport, Communications of the ACM, Vol. 58 No. 4
Architects draw detailed plans before a brick is laid or a nail is hammered. But few programmers write even a rough sketch of what their programs will do before they start coding. We can learn from architects.
The need for specifications follows from two observations. The first is that it is a good idea to think about what we are going to do before doing it, and as the cartoonist Guindon wrote: “Writing is nature’s way of letting you know how sloppy your thinking is.”
We think in order to understand what we are doing. If we understand something, we can explain it clearly in writing. If we have not explained it in writing, then we do not know if we really understand it.
The second observation is that to write a good program, we need to think above the code level. Programmers spend a lot of time thinking about how to code, and many coding methods have been proposed: test-driven development, agile programming, and so on. But if the only sorting algorithm a programmer knows is bubble sort, no such method will produce code that sorts in O(n log n) time. Nor will it turn an overly complex conception of how a program should work into simple, easy to maintain code. We need to understand our programming task at a higher level before we start writing code.