No Projects Please, We're Computer Scientists

Are projects the best (and only) way to teach programming?

There were two aspects of ICT lessons in recent years that had started to bother me.

The first was that ICT seemed to be all about what the end product looked like, and not how it functioned. This meant that many students could make a fairly sophisticated web-site using Dreamweaver and Fireworks but have no idea how it worked.

Using Fireworks, rather than CSS, to create a rollover, for example, not only created a mess of JavaScript that no student ever understood, but also taught students nothing other than the software-specific skills of which buttons to press in Fireworks. Is getting Fireworks to make the rollover for you really any better than getting someone else to make it for you? As the process was hidden from them, many students didn't understand the techniques involved even at a higher level, i.e. that there are two styles that alternate as you move the mouse over an element.

My second concern was that the rise of the portfolio-based qualification had led to lots of extended "project" work with the "teacher as facilitator". Very little teaching went on in a lot of lessons, as students ploughed through the tasks. Students spent all of their time finding three examples of a button, three examples of a banner... etc. and only ever applied their skills once, with no opportunities for mastery or developing their understanding.

I've lost count of the number of students who proudly showed me the web-pages made for their OCR Nationals portfolio, but when asked "How did you make this?", or "How does it work?", would shrug and say, "I don't know."

For me, the switch from ICT to Computing was less about a change in curriculum content than a change in philosophy. There really isn't much in the Computing curriculum that is genuinely new - programming was always in the Developing ideas and making things happen strand, for example, and you could argue that spreadsheet models are really just abstractions.

The essence of Computing is thinking about how things work. It's not about computers, it's about understanding everyday systems and processes with a view to getting a computer to do them, or perhaps make them more efficient. The Chinese postman doesn't need a computer.

This means that you can teach the same topics, and even use the same tasks, but with a different emphasis. You can still make a web-page, but have students understand the process of creating a web-page and consider how it is delivered to the end-user - possibly producing a simpler result, but one that students understand. You can still think about audience, but instead of debating the colours and fonts that users would like to see, you can discuss the need for a page to be rendered correctly on a mobile device using only available fonts, or to minimise the size of the download to reduce loading times and not use a month's data allowance for each page.

This switch of emphasis from what something looks like to how it works also saves time – there's no need to spend ages looking at other examples and perfecting something if that's irrelevant to what you're trying to teach.

It would also necessitate a switch from "teacher as facilitator" to teaching as done it's done in most other corridors in the school.

If you wanted to teach students a mathematical concept - addition, for example - you'd explain what it's for and how to do it, and then get students to practise their new skill. You might start by adding integers, progress to adding negative numbers, decimals or fractions, and then you might even move on to adding other things, such as vectors. You wouldn't briefly explain what addition is and then give students a question that takes six weeks to answer.

What I'm most hoping for from the switch to Computing, therefore, is that we see the end of the "project".

I've never been a fan of the "project" in secondary schools for a number of reasons, but the more I become interested in evidence-based practice, the more I see that the evidence either doesn't support their use or even suggests that they can be detrimental to learning.

My first thought about projects, back when I was doing my PGCE, was that they contained far too much "inauthentic labour". If you're not familiar with the term, inauthentic labour is the effort that students expend in completing a task, but which is only incidentally linked to what you're trying to teach them, e.g. having to type numbers into a spreadsheet before you can use a formula to perform calculations with them.

One of the early arguments for computer-assisted learning was that it increased authentic labour and reduced inauthentic labour, but this has changed in recent years, with the word-processor becoming the new "best handwriting" (i.e. students type text that they have already written).

Projects were about ICT in those days, and often involved tasks related to launching new products – costing, packaging, promotion, etc. They involved researching the costs involved, for example – possibly important in a job, or in a Business Studies context, but does it help you to remember how to use a formula to perform calculations? I've met many students who have successfully completed coursework portfolios containing spreadsheet tasks but who can't use a formula to add together two numbers.

Cognitive scientists tell us that you remember what you think. You might have heard the example of "Willingham's biscuits" – a teacher in the US teaching students about the Underground Railroad got them to bake "bisuits" so that they would remember the diet of escaped slaves. What they actually remembered from the lesson was how to measure flour, mix dough, etc.

That's what we need to avoid when we start to teach programming – we want students to remember variables, decisions, loops, functions, etc., not what colour the characters were or how many points you got for hitting one. We need exercises that get students to only think about programming and not get distracted by the inauthentic labour. Incidentally, this does also apply to ICT – in Willingham's book, Why Don't Students Like School, he explicitly advises against trying to appeal to students' interests by creating spreadsheets of football scores, for example.

Some teachers also think that projects and the teacher as facilitator model allows students to explore concepts and develop their understanding in a form of enquiry-led learning. Again, the evidence doesn't really support this view. John Hattie argues that enquiry-based learning can enhance "deep-learning", but only once the basics have been mastered – i.e. it's of no use to beginners. Daisy Christodoulou goes further and argues that students are being let down by discovery-based learning and that traditional fact-based lessons would serve them better.

As an aside, Hattie's study of what's effective in the classroom, Visible Learning, suggests that "programmed learning" (e.g. on-line courses such as Codecademy) are no more effective than not teaching the students at all.

One of the reasons that I don't like the programming of games in particular is that there is, if the game was designed by the student, no proper analysis of an existing problem. The rules are up to the programmer, and you can write bugs up as design issues – I know; I did it myself for an O level Computer Studies programming project. One of the three programs I created was a Defender-style arcade game, and when I'd completed it some of the characters could only be "shot" from certain angles – I wrote that up as a "feature".

Simple, traditional pre-existing games - e.g. noughts and crosses - can be interesting to analyse but can be surprisingly tricky to program, so are probably best avoided by beginners for a different reason.

Creating a game as a first programming project can also give students a sense that they can walk before they can run - they quickly produce something that they feel is quite sophisticated before they have truly mastered the skills required to reproduce it. I often encounter students who have made games in Scratch and feel that they are competent programmers, but who seem to know nothing in terms of programming technique.

You can't get good at anything without practising – repetition fosters mastery. Hattie says that "teaching and learning occurs when there is deliberate practice aimed at attaining mastery of the goal".

Some people even believe that there's no such thing as innate talent and that expert performance is acquired through deliberate practice. Students, therefore, need lots of small tasks to become competent at something, e.g. programming, not one large task. I aim to give new programmers activities that can be completed in a single lesson – short and focussed, ideally on a single new technique. Students have the opportunity to succeed and create a functioning program every lesson – there's nothing as engaging as success.

I'm not arguing that the software development lifecycle should be ignored completely – it gets a mention in my KS3 programming course, for example. Analysis, design and testing are all important skills for older students, but only once the basics of programming have been mastered and students are able to decompose and code larger problems for themselves. Again, think of other subjects - if you look in a Maths textbook, for example, you will find lots of questions repeatedly testing a single skill and only later is a combination of skills tested in GCSE-style questions.

Old habits die hard, and if you've spent the last decade teaching ICT through projects, your first thought will be to teach Computing in the same way, but it's a different subject. There's a much greater number of concepts involved in programming than in, say, spreadsheets, and they need to be introduced carefully and progressively.

If you're persuaded, I've created an introductory programming course for KS3 students (with Python and BASIC versions). Other sources of short and focussed programming tasks include Project Euler and the Programming tasks and challenges thread in the Ubuntu forum. Finally, if you want to base lessons and tasks on individual programming concepts, I produced a list of Top-Ten Programming Techniques in a previous blog.

This blog originally appeared in the TES Subject Genius series in July 2016.