on programming and process

Software development abounds with processes of course: we have processes for requirements engineering, requirements management, configuration management, design review, code review, test design, test review, and on and on. Massive process documents are written. Huge diagrams are drawn with dozens of boxes to try to encompass the complexity of the process, and still they are gross oversimplifications of what needs to happen. And yet in every one of these processes and diagrams there is a box which basically says "write the code", and ought to be subtitled "(and here a miracle occurs)". Because the process underneath that box is very simple: read the problem, think hard until a solution occurs to you, and then write down the solution. That is all we really know about it.

We don't know how we program.

Some of the comments on this post are interesting as well. Especially that coding is mostly about design. A good design can save a ton of coding and maintenance nightmares. There's another difficulty though in that when you're creating something completely new, you may not even know what you want yet. So there's a lot of prototyping in coding as well. And then your users start telling you what they want, and on it goes.