Remote Learning, The Cathedral and The Bazaar

COVID-19 has forced schools to offer some sort of elearning service. It has forced schools, essentially, to swivel and offer something they’re not used to, at a time of high stress and uncertainty. As teachers, we tend, naturally enough, to look for “solutions” in the direction of education for what works: academic research on elearning, guides on “live teaching” and, less loftily and perhaps more pragmatically, stories from any schools that have managed an even half-way successful prototype. Another fruitful direction is software development, especially open source software development. While it has nothing to do with pedagogy, it provides an interesting set of heuristics with which to design a remote learning service.

Top-down/Bottom-up

A recurring theme in the edutwitter feeds is the push/pull between top-down and bottom up approaches. It’s fascinating seeing bits filter through about what’s working, what’s being offered, and how leadership teams are working. One of the tensions that seems common to all schools, at least those in my network, is how to manage the technology. At the individual teacher level, there are those teachers who want an INSET on what to do and there are those who have been playing around with “bleeding edge” solutions for years and are just itching to have their say. At the group level, there are worries about balancing some sort of standardisation (so that we don’t overload parents and students with 101 innovative solutions that don’t quite work) with using the technology well and wisely. All of those tensions are essentially top-down vs bottom up.

The Cathedral and The Bazaar

Eric S Raymond might have had something to say about these tensions. He coded for and ran a number of open source software projects and wrote his lessons learned in a wonderful book called “The Cathedral and The Bazaar“. The Cathedral and The Bazaar referred to two different approaches to managing software projects, one top-down and the other bottom-up.

The Cathedral model is top down. Software, with its code visible to all, is released at intervals. Only a select few, though, are actually involved in the rewrites.

The Bazaar model is bottom up. Software is developed openly, shared openly and there are no “clergy”. Chaotic as that might sound, it works. Raymond coins what he terms “Linus’ Law”, namely that with enough eyeballs, all bugs are shallow. To put it in more concrete terms, Linus Torvalds is the creator of Linux, the software that is powering at least one third of the web. If you are reading this, you are reading it because of the bazaar.

Raymond’s suggestion is that the Bazaar always wins. Linus’s Law means that the more widely the code is available, the more quickly all bugs (or problems in that code) will be found. The Cathedral model, because the code is only available to the few, will always lag behind.

Cathedrals, Bazaars and Schools

Very coarsely, the Cathedral model is a stereotypical top-down, SLT model. A variant of it might be: design a prototype, make sure all staff follow it, let it run for a bit, and then send out a survey, the results of which will feed into version 2.

Given, though, that speed is a requirement for schools, that the “code” or in our case the elearning service, is almost certainly going to be wobbly when it first comes out of the blocks, I suspect leadership teams could benefit from at least viewing the problem through the lens of Raymond’s advice. If nothing else, it might soften some of the diktat approaches that some have been reporting.

Some of Raymond’s 19 Lessons in School Speak

Raymond synthesised all he had learned from running both projects into 19 “lessons”. These can all, almost, be reinterpreted for school – below are my interpretations but you might find different in your own settings.

1. Every good work of software starts by scratching a developer’s personal itch. Your staff will have different “itches”. The best solutions to remote learning will be found through helping them scratch them and then building on that.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse). Good staff teach well. Great ones, in the remote learning set up, will not be making bundles of new material but working out how to repurpose what they already have.
3. Plan to throw one away; you will, anyhow. This is about versions. (at least) one of the school’s versions of its elearning service will be wrong. So be ready to iterate.
4. If you have the right attitude, interesting problems will find you. The “right attitude” is essentially openness, a willingness to listen to staff, students and parents and a willingness to collaborate.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. This may not apply so much to schools, but if for example the Head of Department builds an all singing all dancing system for one year group, then they need to hand over to someone who can operate it.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. Involve students and parents in the development cycle. Have processes in place for “bugs” to be quickly reported. And say thank you for reporting them!
7. Release early. Release often. And listen to your customers. Obvious to most. Perfection is the enemy of good. Don’s see this as one long parents’ evening! Talk, iterate, explain, get feedback.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. The more people you involve in developing a solution, the better the initial prototype will be. This includes, I think, involving the technophobic as they are critical to making any system robust.
9. Smart data structures and dumb code works a lot better than the other way around. In a school scenario, “data structures” might be things as simple as having a standard naming convention for lessons and classes and “code” is the letter sent out to students and parents for what they’re meant to do. It’s better to have a data structure that people can access easily and then fit to their own needs.
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource. Actively seek suggestions for improvement from staff, parents and teachers. Say thank you to each. Let them know when you’ve implemented a change they’ve suggested. And then seek more suggestions for improvements
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. Same in schools
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. From what (little) I’ve seen, this again comes down to listening to parents and students. Parental feedback is obviously key: allow them to say, for example, that “we’re both working and what you provided was a nice idea but needed us to stop working to explain it – give us activities that let us work”
13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Same in schools.
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. Be on the look out for the ways everyone is using your service. If you spot a new innovative use, then highlight it and support it. So for example if you see students giving each other tech support on something like Showbie, make a virtue of it and make a whole school tech support Showbie group.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to! Not sure this applies.
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend. Be human in your comms. Give people two ways to understand what is being said.
17. A security system is only as secure as its secret. Beware of pseudo-secrets. Not sure this applies to schools.
18. To solve an interesting problem, start by finding a problem that is interesting to you. Give staff free rein to identify problems they see, share them and then come up with prototypes together.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. This, for me, is Management 101.