Here’s a quote from Turing Award–winning computer scientist, Leslie Lamport;
“few programmers write even a rough sketch of what their programs will do before they start coding”.
Programming author Samer Buna believes a fundamental beginner’s mistake is to start writing code without planning. Suggesting that writing quality programs is a process with a flow. Namely;
Think – Research – Plan – Write – Validate – Modify.
When I first saw this, it reminded me of various PDCA-type cycles which add an Evaluate or Observe style stage to the start. Yet this one has two extra components at the beginning.
It might also remind you of the classic preparation wisdom; “give me six hours to chop down a tree, and I will spend the first four sharpening the axe”.
Planning in general though sadly seems a diminished, untreasured corporate discipline. Time spent mapping a course can look like a distraction. Be dismissed as a waste because nothing tangible may arise to be physically seen. And the longer such phase goes on, the more a superior may panic because they want to see what they call actual work done and demand it begin regardless, ‘now’.
Yet I firmly believe this ‘puzzling out’ stage is vital. In the above coder’s cycle, it accounts for half the overall stages. With three separate pieces.
Maybe we must amend the language. Can for instance, a project’s planning phase(s) be re-labelled proto-project-ing? Or any derivatives of that for your specific project term.
Interesting for any endeavour.
Yet also I wonder how relevant and useful this would be to frame a conversation with a prospect issuing a tender.
They would I dare say, expect any discussion with a potential vendor to focus hard on the specifications and requirements documented.
Be different. Be distinctive. Be desired.
What was your thought process behind this project?
What research followed?
What planning did you then go through?
What then went into writing your needs up?
What validation of them took place?
What modifications emerged or are anticipated?