Open Course Development

It strikes me that, whilst I am deep into the design of a number of programming-related courses, I am making a terrible mistake. The mistake of not talking about what I'm up to. The mistake of assuming the entire burden of course development.

Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.

Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".

"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.

"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.

And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.

I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.

I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.

So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)

I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"

Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.

As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)