Ready, Fire, Aim–Why Is Design First So Hard To Learn?

“Hours of coding can save you minutes of planning”

We’re talking about top-down design in my APCS Principles class this week. I gave the students a worksheet (part of the code.org curriculum which is really well done) that asks students to pair up and design the functions they would write for a given problem. The first question from a student? “Do we have to do the design before we write the code?”

Now you may be asking yourself – what sort of question is that? Of course you design first. That is not how students think some times. They want to jump right in and write code. It’s not that they know how to do it or that they have a design in their minds though. They want to try things and see what works. They are more into trial and error. They have high tolerance for error as long as they are moving forward and the development environment is not giving them error messages.

Now not all students are resistant to planning. Over time most students come around to the idea of design first. It can be a tough sale though. Design doesn’t have the same instant gratification that writing and trying a line of code does.

Back in the day (yeah, old guy reminiscing) we had long turn around between writing code and seeing results. We handed in our deck of punch cards and waited (hours or even days) to find out what worked and what didn’t. We really could not afford to skip the planning phase. We thought deeply about how things should work.  We closely desk checked code before submitting it and after getting early results.

Now I am not saying I want to go back to those days. (even though in weak moments I might think it would be good for students.) I do wish it were easier to keep students from writing code first though. I’ve tired having one student write a design and than having another student write code from it. The second student tends to mostly ignore the written design and do it their own way which may or may not look like the design at the end. Often it is easier to blame poor design than a failure toe follow the design. Students do want their programs to work and they don’t want to make peers look bad.

What I am trying to do more and more is to model design thinking myself. We create programs as a class and I work though the design before showing code. For example, we are working on a program to give and score quizzes. We worked though a discussion of what a question class would look like. What data would it store, what functions would it need to support, and how would it be used?

I can force students to write out designs. And they’ll try. Over the years though what seems to influence students most is what they see me do.  If I get lazy they’ll get lazy. If I take shortcuts they’ll take short cuts. If I use good practices though so will they. If I model design, planning for expansion, and show that I am thinking beyond the near term so will they. I keep reminding myself of this.

Leading by example is the best tool of all.