Opening remarks on the above for a BETT Futures panel.

Hmm… ‘integrating technology and creating the best computing curriculum’. It’s lovely to be part of the panel, but the title did strike me as odd. I think this is because of its attempt to blend together two quite different, although admittedly related, themes. Are we to discuss integrating technology – surely something which should be, and largely is, happening across every area of the curriculum and the broader life of the school, or are we concerned with creating the best computing curriculum. These aren’t incompatible aims, but they’re certainly not the same.

Is there one solution which will fit both? Perhaps. Let’s try thinking about these two problems as we might look at a software development project.

Back in the old days, developers in ‘the industry’ would approach projects using a thing called the ‘waterfall development methodology’: I think there may be parallels in our world. We start with someone, usually with a nice office, coming up with broad requirements: ‘teachers should use whiteboards, pupils should have tablets, children should learn to code’ or whatever. Others have the job of working those up into detailed specifications – I was fortunate enough to be part of the panel that drew up the computing programme of study, so I know whereof I speak; blame me or thank me. Others have the job of implementing those specifications, typically without much say in the specifications. In our line of work we call these folk ‘teachers’. We then need to check all is as it should be – testing is hugely important in software engineering, and forms something of a focus in our line of work too, although I do worry a bit that we’re not as good as software developers at debugging the problems that arise. When things don’t seem as great as they should be, ship out the service pack. IWBs not all we thought they’d be. Try visualisers. Laptops and netbooks failed to deliver? Try iPads! Sooner or later, something’s bound to work, yes? We know from projects such as the NHS Database just how successful this approach is in software development, so it’s bound to pay off in education too, isn’t it?

Other approaches are available. These days, you’re more likely to find developers adopting ‘agile’ methods, which emphasise getting software that works rather than documenting the process comprehensively, which emphasise individuals and interactions rather than processes and tools, collaboration rather than contracts, responding to change rather than following plans. I suspect most of us went into teaching because these are close to what we value too. Our trainees have to plan their lessons, of course they do; but any who’d rather be writing lesson plans than, you know, teaching, may have chosen the wrong career. So yes, planning technology integration or a computing curriculum matters, but not nearly as much as actually integrating the technology or teaching computing.

Agile methods get you only so far though – applying them in our line of work can seem just a bit too similar to the ‘child centred education’ which Wilshaw, Gibb and others so deride. I think what we need is closer to software craftsmanship. What we do has to be closer to architecture than sculpture – our integration of technology, and our computing curricula, have to be useful as well as interesting; neither ought to be an end in themselves. Yes, let’s use great tech, but let’s use it really well. Or a fun, engaging computing lesson can only be outstanding if your pupils leave understanding more than they did at the start. Yes, do focus on the pupils in your class, but don’t lose site of the wider community of practice of which you’re a member: share your successes and failure, both in terms of technology integration, and how you’re teaching computing. CPD is about developing the profession, not just developing as a professional. For both technology integration and computing education, there’s a real need for us to develop not just our professional practice, but the practice of our profession.