There’s much more to software development than coding: the process of developing software has much in common with other engineering disciplines, and so there are some close parallels with design-make-evaluate projects in Design and Technology on the school curriculum.

The first stage of developing any software project isn’t coding, it’s planning. To plan the project as a whole, and to plan how the computer will be programmed draws on the set of computational thinking processes I’ve blogged about elsewhere.

Typically developers need to understand a problems or system before they’ve any chance of being able to develop some software for this, and that’s likely to draw on processes such as logical reasoning, to identify the relationships between cause and effect, abstraction, where they’ll focus on the key features of the problem or system, leaving others to one side, and pattern recognition or generalisation, where they might think of other projects which have something in common with the current project, looking to see if there are aspects of the approaches or solutions to these which could be re-used. Decomposition is really important for breaking big projects down into manageable tasks, and algorithmic thinking is necessary to plan how these will be tackled.

Developers will also need to draw on computational thinking in first designing their programs before they start coding. How formal this design stage is will vary from one development methodology to another, but there’s always some thinking and planning necessary before the actual coding can begin.

Waterfall

In traditional ‘waterfall’ software development, a single path is planned through the project from beginning to end. If a bespoke solution is being developed for a particular client, the project will start with the client working with analysts to specify requirements for what the software needs to do. A more detailed specification can then be worked up, which will include much of the technical planning for how to program a solution, including consideration of systems, language, algorithms and data structures, but no actual code. The specification then gets implemented as code in whatever language for whatever system has been decided- often this will be by a team of developers, each weighing in on one or more particular parts of the project in parallel with others. The next stage is to test the code rigorously, making sure that it has no bugs and that it meets the detail outlined in the specification and the original requirements. There’s usually a fifth stage in commercial waterfall development in which the software house undertakes to maintain the program, updating it if necessary to meet changing requirements. Waterfall methods are still used for some big, public sector software deployments. And we all know how successful they are.

This approach has something in common with curriculum development – moving from requirements that children should be taught computer science, IT and digital literacy through a detailed specification of programmes of study to implementation through schemes of work, lesson plans and activities to testing and evaluation, with further support there if necessary.

Iterative development

In iterative development, the process of designing, coding, testing and evaluating becomes a cycle rather than once and for all. Most modern software development fits into this pattern or a variant of it, hence new versions of software are regularly released which fix bugs that only became apparent once the software was released, or implement new features, in response to customer suggestions, technical innovations or market pressures. Often developers will release an early ‘beta’ version of their software, perhaps to a limited number or quite openly, to get help with testing and evaluating the software before committing to an official final release. This is common practice in open source development, where the users of the software are positively encouraged to help with fixing as well as finding bugs or adding code for new features themselves.

There are parallels between the design – code – test – evaluate cycle of iterative development and the plan – teach – assess – evaluate cycle for teaching that many teachers and schools now use routinely. Similarly, just as assessment for learning has produced a tight loop between teaching and assessing, so that the results of formative assessment feed directly in to how the rest of the lesson or unit of work proceeds, so in iterative development, there’s a tight loop between coding and testing – as bugs become apparent in testing, they get fixed through more coding – this process is called debugging.

Agile methods

Whilst recognising the importance of things such as planning, agreeing requirements and producing documentation, agile software development moves the focus of the effort to producing working, usable code, typically much earlier in the process. It also emphasises the importance of collaboration with users and responsiveness to change. Whilst by new means universally accepted, the effectiveness of agile methods in getting to a ‘minimum viable product’ and then developing this further in response to changing needs and rapidly developing technologies has made this approach popular with many working in technology based start-ups, as well as for developing new online tools and apps for tablets or smartphones.

The emphasis in agile methods on individuals and interactions, collaborating with customers and responsiveness to change might put us in mind of the ‘child-centred education’ pedagogies of an earlier generation, and perhaps even today there’s scope in some computing lessons for supporting and encouraging pupils as they pursue individual, independent projects or their own lines of investigative enquiry.

So which approach should we use in class?

The national curriculum for Key Stage 2 expects that pupils will have some experience of working on larger software projects than just learning the key programming concepts of sequence, selection and repetition:

design, write and debug programs that accomplish specific goals

The way you go about this though is up to you! Choose the approach which would work best with your pupils, and for the particular project you (or they) have in mind.

It’s perhaps best to let pupils have some experience of all three of these methodologies. For some programming projects, you may only have time to work through from planning to debugging and evaluation once, in which case guiding pupils through the waterfall process may make most sense. Other times, it would be worth taking a more iterative approach, getting pupils to look for ways in which they could add further features to their programs, improve the user interface or refine their algorithms, as well as emphasising repeated coding, testing, debugging as part of the programming process itself.

Pupils who find that they really enjoy coding and choose to do this independently outside of formal lessons might often adopt an approach with much in common with agile methods – there’s anecdotal evidence that this is often the case for those contributing to the Scratch community or taking part in the Kodu Kup. You might like to look for ways to facilitate this approach in curriculum time too: perhaps setting very open challenges to pupils, eg ‘make an educational game’, providing support and challenge as needed as well as encouraging pupils to help support one another as they rise to meet the challenge.