To plan or not to plan that is the question

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).

Answer 1

Programming involves a mix of long-term and short-term planning.

Long-term planning involves questions like:

• What is my end goal?
• Who is my audience?
• What does a minimum viable product look like?
• When are my deadlines?

Students are often faced with a feeling of "I don't even know what this is asking me to do" when given an assignment. That's where long-term planning comes into play. Maybe have them rewrite the assignment in their own words, or ask a series of questions that help them understand what's expected. Stuff like: What's the input? What's the output?

Short-term planning involves questions like:

• How can I break my end goal up into smaller steps?
• What is the smallest thing I know I need to do next?
• What code do I need to write to accomplish my current step?
• Have I considered corner cases for this step?
• How can I test that this step works?

This is where a lot of programming lives, in the process of breaking things down into smaller steps and then taking action on those steps. The steps need to be smaller than the student thinks is interesting, that way they can actually write code that accomplishes that particular step.

There is a bit of an art to both kinds of planning, and they're both required by anybody who writes code. They're also very hard to teach, other than having students work through the process themeselves over and over again. I like to say that anytime a student has been given a homework assignment where they didn't know what to start, the real lesson was not regurgitating syntax: it was teaching the process of breaking a problem down into smaller pieces and then taking those pieces on one at a time.

Shameless self-promotion: I've written a tutorial on this stuff available here.

Answer 2

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.

Answer 3

I will take a tip from one of the more experienced project managers that I work with. Some people like to plan everything in great detail, and will miss some of the things that practical experience will give them. These people need to be encouraged to take a break from planning much earlier than they feel happy with, and at a minimum start prototyping the bits they think they're happy with, or the bits they're worried about getting right.

The other people, who jump straight in - give them time to start to make a mess, then help them to break what they have started with down into a plan. If they started perfectly, get them to rough out a plan of the bits they haven't thought about.

Effectively, there are two decisions to make. Push/pull and which end to start from - both reacting to an individual's behaviour and comfort with the task. Assuming these 4 models are all valid to some extent, it is hard to drive the plan/implement cycle in a single way with a large group. You can however teach the process then guide people to find a way of delivering using it.

Answer 4

I believe you can't form a workable plan without experience.

You can guess about what to do, but, imho, that's a complete waste of time. My approach here would be to help these kids get experience.

To do that, consider how apprenticeships work. The apprentice shows up with nothing other than the desire to learn. The teacher shows them each step. Here's how to declare a variable, here's how to add numbers, here's how to get input from the user, etc.

After they've learned the basics you take them through building an app. It should be something simple like a calculator. You lead them through the design, asking leading questions along the way. Point out what choices you have to make in the design. Then, have them code it to the design specs.

Now that they've been through it, assign a project and let them lead. Again, keep it simple. If they hit any roadblocks, ask leading questions to see if they can identify the problem and work through it. If they can't figure it out, point them on the right path and explain the reasons.

Rinse and repeat for bigger stuff.