To plan or not to plan that is the question We are often asked to plan: We are asked to make lesson plans; When I was a programmer sometimes I was asked to create a plan; We are told to ask our students to plan their projects.

However there is often a problem with this:


As a programmer,
I could not plan everything upfront. There is a lot of discovery in the development process. If we knew what we were doing then it was because we had done it before. If we had done it before, then it was a bug that we were doing it again (we should be reusing).
As a student,
I have been in a class room where a teacher has told students to plan / design a project, and that then after that they would be taught how to program it. This often does not go well, as students can not plan for something that they have no experience of.
Teachers seem to think that this is the “Correct way to do it”.


Another approach is test driven development: Ask what next, Write simplest test that will fail, Write simplest code that will make test pass, re-factor if needed, repeat. This works most of the time. However, there are times when it does not. For example, the other day I was making an adding machine out of lego (my own design). Part of the build was tinkering and experimenting, but for part I stopped and wrote a plan. It was easier to plan on paper than as I went along, as mistakes could be fixed more easily (it is hard to fix an error in the middle of a lego model, you have to take it apart).

I seem to have an intuitive feel for planning (just enough, and just in time). However this is probably not a good explanation to tell others.

When students are doing project work,
When is planning and high-level design a good idea? When is it not? How do you tell the difference? And how do you teach this to the students?



I work with pupils years 10-11 (age 14-16), and 12-13 (age 16-18).
As you suggest, it is a subtle question. Twenty-five years ago, the answer was simple: Plan. But too many software projects crashed and burned because of over-planning and sticking to the plan after it was obvious to all that it was the wrong plan. More recently, the initial failure of the signup system for the Affordable Care Act was likely caused by this same failure of thinking. 


Plan if you can, but be flexible enough to deviate from the plan when needed. 


That sounds like good advice, but it can, itself, be the root of too many problems. If you have a complete plan you are likely to be willing to expend resources at the beginning that will only recoup their investment if it proves to be the correct plan but will be wasted (sunk cost) if the plan proves to be incorrect. 

So, with a complete plan you can build the thing at lowest cost if the plan was correct. But you wind up with a failed project otherwise. Not only have you spent money on the incorrect plan, you have expended time and your competition may have moved ahead with a better solution. You are both late and poor. 


When you can't plan, build on a tight feedback loop. 


That is the key message of Agile development. All of the practices of, for example, Extreme Programming and Scrum flow from that message. The implication is that you don't expend resources on speculative assumptions about where the project will go. It does mean that (a) you sometimes can't take advantage of economies of scale and scheduling but (b) you don't get caught with sunk cost that you get no benefit from. In today's development environment (rapid change) this is usually a better assumption to make. 



My advice to educators is to learn everything they can about Agile Development, whether you decide to adopt it or not. The ideas are interesting in themselves and can prove transformative if not viewed too narrowly as just a set of practices. 

And, of course, read the Mythical Man Month. Its message is valid yet, though it was written for the BUFD (Big Up Front Design) era. 



Note that agility goes beyond software development. The principles of agility (see the Agile Manifesto) can be reapplied in different ways to vastly different things.