Ever since I entered teaching the debate on “How to teach programming” has been raging. It is still something that a great many of us struggle with. That struggle relates to our need to constantly revise, rework and redefine our approaches to programming and software development with our learners. I’ve lost count of how many times I’ve rewritten my programming notes for Standard Grade, Intermediate 2 and Higher Computing.
What I find difficult to reconcile with our current certificate courses is the requirement to analyse and fully understand an entire problem before you do any design or implementation. The approach dictated, as I’ve on commented before, is the waterfall model (developed in the 1970’s) which is a formal, predictive method of creating software. It relies on establishing the entire future development of the project from the start and changes after the initial analysis and design can have a significant effect, often requiring the project to be restarted. These predictive methods do not allow developers to respond quickly to change or to quickly develop working prototypes to share with clients. These formal “heavyweight” methods are heavily regulated, regimented, micromanaged and depend on the waterfall model of development.
From a learners perspective, these methods put the emphasis on documentation and process rather than on programming skill and problem solving. We need to adopt development methodologies in school which allow our learners to be creative and ingenious as they develop software solutions to problems. That is where Agile methods come in.
Agile methods, can be traced back to the infancy of computing and the evolution of Agile methodologies can be seen in incremental programming and the rapid application development methodologies popular in the 1990s and onwards. The term Agile, comes from the Manifesto for Agile Software Development, which was published as a result of discussions by 17 software developers, some of which went on to form the Agile Alliance, a nonprofit organisation which promotes development based on Agile principals.
But what in Agile methods, is so appealing for learners and teachers? Agile methods break the elements of the the project down into small tasks which require minimal planning. The developer then goes through a full software development cycle for each task. The emphasis is on working software and on face-to-face communication with the client rather than on written documentation.
In schools, this Agile approach would allow learners to focus on incrementally developing individual features of a software development project, rather than analysing and planning the entire project from the start. Learners follow an approach of design/build, test and repeat for each iteration of the software. Features of the software can evolve through the implementation and because the focus is on working software, candidates should receive credit for their software development skills rather than for how good they are at writing a report!
An Agile approach is about responding to changes and developing software. When I look at learners in P5 to P7, developing their own games with Kodu or Scratch, this is exactly the kind of software development they are involved in. They incrementally build the program, creatively responding to changing requirements and with an overall focus on producing working software. And they are fully engaged in the programming activity because the emphasis is on creating something wonderful with the software and not on rigidly following a formal software development methodology which takes all the joy out of the programming activity with an over emphasis on relatively meaningless documentation.
We need creative problem solvers first: the documentation and formal methods have a place but not at the sacrifice of creativity and ingenuity in software development.