Back in the old days, when I coded for Windows, it was relatively easy to reuse code. Small software houses would do a good business in supplying code libraries that would take care of a lot of the grunt work, like dealing with compressed files, GUI components like tabs (this was in Win16 days before the Win32 tab control came out). Most coders I knew designed them themselves, as a matter of principle but if the boss was breathing down your neck, it was easier to get him to sign a purchase order and save a couple of weeks dev time, than sit down with a large pot of strong coffee and an IDE. Windows itself has massive code reuse, in the form of the common controls, dialogs, windows etc. It was eezy-peezy to knock up an event driven gui in an hour or so – and it did something useful.
This was all fine, working in a “vertical” development environment, where your customers were (mostly) guaranteed to have a predictable end system (windows) and all the required libraries would be there and waiting for your app to drop in. Well, that was the experience for gui apps. Kernel/printer drivers were another thing altogether. It got so messy in NT3.51/4 that MS scrapped the kernel mode drivers and moved them back to user mode – hooray, you could debug without SoftICE! There was less code reuse at the driver level but it was there, somewhere. Remember, it was still a vertical market – windows and C/C++
Then they decided to move horizontally and let other people (VB) join in the fun and COM was born. In reality, they just fatted out the vertical to make it look horizontal. Using COM outside Windows could seriously damage your health and your keyboard. Anyone with even rudimentary coding skills (VB ) could implement a COM object and participate in the new reuse model – binary level reuse. It bristled with interfaces, 15 miles deep and when it was apparent that objects needed network resources, DCOM was brought in and the interfaces doubled and were marshalled and unmarshalled and I gave up and wanted to become a baker!
Now, they’re back with software factories . The idea is to have a few talented individuals designing the world and the rest of us use what they produce. Sounds like it’s another attempt to gather together the scattered VB community and fatten the vertical even more.
Anyone who’s ever tried to reuse code will tell you that it’s mostly ok, until you hit the first problem, then you end up patching it so much it turns into something completely different and completely non reusable! So, the high heid yins say, design for reusability. For a closed world assumption, maybe that could work, just maybe but in the real world, how on earth can a developer know to what uses their software will be put? There are loads of vertical industries out there that produce software that only their particular environment can use. The less obvious horizontal spar linking them is MS. They’re reusing code but they probably don’t know it. If they replaced their Windows environment they’d have to rewrite almost, if not all, their software.
That’s the danger in having a few gurus telling the rest of us how to design software. The uses can only be guessed at, so the reuse is limited, with the greatest benefit to be had if you shift to their environment. There’s a lot of talk on service level reuse (I call it that) where you can reuse what are essentially binary objects, so you’re back in the DCOM arena but it’s far easier to glue them together as they’re available via web service standards such as SOAP. Standards and MS don’t mix though. Have you ever tried getting a *nix LDAP application to talk securely to an ActiveDirectory server? and MS have also now poo-pooed UML
That’s all interesting I hear you say, you sad unix dev. If you live in winLand you won’t have any problems and there will be tons of modules you can reuse. You won’t even have to write any code, you just drag/drop/release. The user tests as before
So, the state of software resuse at the code and binary levels has oscillated between a thin vertical strip of winLand with the occasional gastrointestinal bloating to fatten it out a bit into the fringes, where the crazies live. People who spend their nights implementing undocumented interfaces to talk to the denizens of winLand, just for the hell of it.
The title of this story contains Learning. So where’s the bit about Learning then? Coming up.
I’ve heard a lot about reusable learning objects lately and it’s started the old COM scars to pulsate, especially when I hear the mantra of reuse. Projects such as Reload propose learning object packaging but people are starting to jump on the bandwagon, thinking it’s going all the way to the terminus, when in fact the road stops at the root node.
You jump on the learning object reuse express, you pays your fare and the conductor hands you a ticket that says getDocumentElement(); Coz that’s what you get. A tagged stack of XML. You know what it is, what it does and what it can be used for, as it tells you that in the XML description. It’s like buying a car and having it delivered to your door. You jump in and start tugging the steering wheel from side to side but the car don’t move. It should, that’s what the movie stars do. They tug the wheel from side to side and the car moves! Then you realise you have to do something else before it’ll move. You have to learn to drive. To combine your static, on the pavement scratching your head state, with the static object you’ve just bought, to produce a moving vehicle, will take glue and that glue is driving lessons. Nowhere in the brochure for your lovely new Trabant does it say you’ll need driving lessons before being able to “reuse” this car. Of course, you could just build your own car, with pedals and it’ll move just fine but you’re trying to reuse someone else’s car and as you don’t meet their reuse requirements, you can’t reuse it.
This is the whole point of the story. Before you can reuse anything You Must Do Something Else. Something that you wouldn’t have to do if you’d built your own.
So you’ve got a load of learning objects you’ve pulled out of someone else’s CMS, such as DSpace and you’re dragging and dropping, trying to get your users to learn something from all these objects. The point is that, from software reuse experience, reusing anything without some sort of proprietary glue just will not work. Unless, of course, you decide to join the vertical and ignore the occasional intestinal bloating.
If everyone taught in exactly the same way, then learning object reuse would be a doddle. You wouldn’t need to be creative and design glue to stitch them together in a fun and novel way. You’d just download and reuse. That used to be called plagiarism. If I copied large tracts of material from the ‘net and produced it in an exam, I’d get a steel toecap up my bahookie but it’s OK to produce courses in that way. Search/Download/Release. Sounds a bit like drag/drop/release to me.
Is learning object reuse going to lead to the homogenisation of eLearning? Probably not. As MIT know, the value in learning is not the content but how it’s presented. The pedagogical model. The glue.
So go get them thar reusable learning objects but get your fingers sticky too