Most programming is a variant of “cut and paste” programming. You find the archetype you’re looking for, adapt it, and then paste it into the program from a mixture of sample code and blog posts. It works; you move on.
Some programmers are even more experienced. Their pattern recognition and Pavlovian syntax response is all in their heads. They see a situation, and dump code from their fingers in response.
Others even have a way of looking at the whole project, making it an assessment of how the code should be shaped, and putting it together. Their syntax is on the level of the shape of the overall program.
The problem with each of these method is that they’re limited role. The programmer is the only one involved in how the project works; the major architectural factors unique to the project are removed; and, it’s difficult for others to participate.
Leslie Lamport wrote a powerful suggestion for architectural and collaborative (with client interests) software design, as opposed to reflexive syntax generation by pattern recognition:
Most programmers regard anything that doesn’t generate code to be a waste of time. Thinking doesn’t generate code, and writing code without thinking is a recipe for bad code. Before we start to write any piece of code, we should understand what that code is supposed to do…
I recently modified some code I hadn’t written to add one tiny feature to a program. Doing that required understanding an interface. It took me over a day with a debugger to find out what I needed to know about the interface — something that would have taken five minutes with a spec. To avoid introducing bugs, I had to understand the consequences of every change I made. The absence of specs made that extremely difficult. Not wanting to find and read thousands of lines of code that might be affected, I spent days figuring out how to change as little of the existing code as possible. In the end, it took me over a week to add or modify 180 lines of code. And this was for a very minor change to the program….
These days, the few programs I write are more like bungalows than skyscrapers. I usually specify each method, and most methods are so simple that they can be specified in a sentence or two. Sometimes figuring out exactly what a method should do requires thought, and its spec may be a paragraph or even a couple of pages. I use a simple rule: The spec should say everything one needs to know in order to use the method. After the code has been written and debugged, no one should ever have to read it. – “Why We Need Specs,” by Leslie Lamport, Wired
Lamport is one of the foundational thinkers in the field of distributed systems. He works for Microsoft Research and has contributed to fields tangential to philosophy with his notion of the temporal logic of actions (TLA).