This article is more than 1 year old
Educating Verity the OU way
'The skin of my C++ custard remained unruffled'
Stob I think I mentioned that I was doing an Open University PGDip course in software development. (For those not familiar with the institution, the Open University has rightly been described as a sort of mental gym. You join with great enthusiasm; then, after three months, having attended just twice, you can drop out and ask for the balance of your subscription back.)
Well, after four years at it, I have finally finished, and want to share.
One of the skills we were encouraged to develop was the writing of highly compressed summaries. So here is the essence of all eight modules, 23 homeworks and any number of learning outcomes, bullet points, bolded key terms and self assessment questions – zipped up into one Reg article.
You may not learn quite as much as from the real thing; on the other hand, my version is £8k cheaper.
Oh, and I have carefully included cover illustrations from each of the modules, to enable you not to judge the content by them, and in support of a theory of my own viz that graphic designers as a profession don't half put out some rubbish when required to portray software development procedures.
After Rita
Forget about Michael Caine and Julie Walters and all that. There are no cosy, one-to-one tutorials in book-lined studies, with Johnnie Walker bottles hidden behind the TS Eliot. Nor yet are there 2am lectures on BBC2, presented by black-and-white professors wearing '70s sideburns and kipper ties.
Nope, there are three main planks to an OU PostGradBizCompSci course:
- reading the text;
- doing the homework; and
- suffering the exam.
All this with not much interaction with anybody, although you do have the right to email your tutor, and to participate in rather desultory online forums. The OU is not an alternative to social networking: more CutOff than LinkedIn.
The modules available to us D69 students divide into two broad categories: "hard" technical topics (OO, databases, web), where you get to dirty your hands with code; and "soft" humanity-oriented topics (UI, requirements, management), where you don't.
SAQ
Propose a framework to distinguish between "hard" and "soft" topics.
Here is a simple test that we devised; there may be other correct answers.
Are there pages somewhere in the module text advocating the delights of "brainstorming"? If so, you may be sure you are on a "soft" module, which cannot resist recommending the technique. Whereas nobody advocates writing code by having everyone stand around and shout out their random ideas. (Although, as it happens, this is a much more effective technique than, say, CASE tools.)
As a hater of essay-writing, I was drawn to the cheerful, puzzle-solving ground of the "hard" subjects. But actually, excepting the SQL module, there really isn't much puzzling. I exaggerated with that "dirtying your hands" back there: the most you can expect is a light smearing. Java is adopted as the lingua franca, but never in sufficient depth as to ruffle the skin of my C++ custard.
But it was on the "soft" courses that I learned the most. For example, the software management module M882 included the following nugget which, shamefully, was quite unfamiliar to me (and shame on Wiki too, for doubting its notability). Meir M "Manny" Lehman's Software Uncertainty Principle possesses that strong indicator of a top-notch insight: once explained, duh, the thing is obvious.
CASE STUDY: Brother Lehman's Uncertainty
Brutally summarised, Lehman says: as you code, you weld into your program certain assumptions about the universe. Osmium is the heaviest metal, VAT is 17.5%, Windows stores custom properties of files in alternate NTFS data streams, night follows day. As time passes, some of these assumptions inevitably fail, and so, equally inevitably, the once-reliable program ceases to work properly. Of course, if you are aware of a dodgy assumption at the start, you can protect yourself or hoick it out; but the universe is infinite and your program isn't, so you can never get them all.
Thus it is that software rusting is explained: real-world applications can, and eventually will, go from working to not-working without flipping a single bit. Encapsulated inside them are the now-wrong assumptions, like fossil insects in amber. No, that's not right. One can see through amber. They are like fossil ferns embedded in coal, which can only be rediscovered by smashing the lump with a hammer.