Interesting things

Sorry if I have become a Java-hater, but I really did not expect a language with so many deprecations to run after all these years!  As explained here I was one of the first people to write a rather large application using the relatively new “Swing” library,

If you are interested in downloading it, here’s the link: DataScan V357. Just don’t make fun of my dirty code!

Continuing the series, now I want to summarize where Constructive Alignment as a didactical tool falls short – and how I would fix it.

I said it in my last blog. Whereas John Biggs did a great job of connecting learning outcomes with learning activities and learning assessments, a connection to the real world — to the WHY — is completely missing.

Fortunately, this seems very easy to fix, as shown here:

 

In other words, the real world goals — the WHY — feed into the learning outcomes.  In my next blog I’ll give a concrete example of how this could look in a real-world teaching situation.

 

Continuing the series, I want to show why I think Constructive Alignment falls short – and how I would fix it.

Always start with the WHY.

Maybe there are teachers who teach in order to teach. Fair enough. But as a scientific and engineering oriented guy, I’ve always thought teaching has a very applied aspect. In this context (and I admit it is not the only one!) students should be getting skills and abilities that they can use in real world situations.

So in this blog, let’s focus on an IT student that graduates from an IT program and joins the IT industry. Working in this IT industry will require knowledge that she has learned.  Probably there are existing maturity models that can classify this situation, but this one seems pretty reasonable to me:

Now if you jump back to my first blog about Constructive Alignment, perhaps you can see where my discomfort is beginning. Constructive Alignment seems to be a very practical tool; indeed, the whole “didactical” world seems to love it!  It clearly connects learning outcomes with learning activities and learning measurements.

But to my the most fundamental and important point of dissatisfaction: a connection between learning outcomes and real-world skills and abilities — in other words, the WHY for learning — is missing!

More on this in my next blog.

Let me start with a disclaimer.

DISCLAIMER: I spent more time in my life working with computers than any other topic – and I am no computer expect. I spent more formal time in my life studying physics – but I am no physics expert. So considering that I have only been dabbling in educational research (known as didactics – which sounds more scientific than I think it really is) for a few weeks, the reader is well-advised to take what follows with a massive 20-ton block of rocksalt!

OK, having appropriately disclaimed myself, in this blog I present a leading didactical idea called Constructive Alignment.  In my next blog I’ll talk about why I don’t like it – and how I would improve it.

Within educational circles — and please let’s park the discussion about how scientific these circles really are! — the idea is known as Constructive Alignment. It’s due to a fellow named John Biggs, who even has his own website. As a simple guide to preparing very effective teaching materials, he proposed linking the learning goals and the learning activities and the learning measurements. In his own words, “In constructive alignment, we start with the outcomes we intend students to learn and align teaching and assessment to those outcomes.”

[ASIDE: If you have some time, surf to John’s website and you’ll be glad you did. He has a wonderful collection of essays and a general Asian perspective.]

I found this very pretty picture of Constructive Alignment here:

As far as I can tell from Mr. Google, whether it is scientifically justified or not (I’ve seen no experiments) this model seems to have found widespread application throughout the academic world.

In my next blog I’ll say why I don’t like it – and how I would change it.

The idea of a Googlewhack has been around for a long time: it’s when you stumble on a search phrase, no quotes, that returns exactly one result. It’s called a Googlewhackblatt when you do it with just a single word as your search phrase.

Well, not only did I stumble across a Googlewhack, but I did it in one word!

 

I was just writing a lesson about “computer drivers” and “database drivers” for my database class when the following idea occurred to me.  Not sure if everyone will agree.

A driver is like a slavedriver

It sounds a lot like slavery, and it is.  The driver does all the work. It does not ask any questions. It does not get paid. Most people don’t know it exists. And it only complains when it is asked to do something that it cannot.  Probably one day, if you are born again, then in a future life it is better to be born as a computer rather than a driver. Unless you really like being a slave.

Here’s a good picture of a slavedriver:

The Product Owner (also called PO in the agile world) is the guy in the background wearing a gold armband and indicating where he wants the big stone moved to.  He doesn’t care about the details: what kind of rock, how many slaves are needed, or how many ropes.  He just knows where he wants the big stone.

The slavedriver (called ScrumMaster in the agile world) is the big bald guy with the earring holding a whip. The slavedriver gets his very generic instructions from the Product Owner, then uses his detailed knowledge of the specifics (type of rock, how much friction, how many slaves, what kinds of rope, whether to use a lubrication such as water or sand, etc.) to “motivate” his team to do what the Product Owner wants. It’s all about motivation.

If the people are all suffering, we call this slavery. If the people are all having a good time, we call this the Agile Methodology. But both are the same.

A mathematician would say “slavery and the agile methodology are topologically equivalent to each other.” In the field of computer science or enterprise architecture, we use the term “separation of concerns.”  The Product Owner is concerned about getting the big stone to where he needs it; the slavedriver and slaves are concerned about the details to make that happen.

In short, the slavedriver makes the connection between the generic world (of the Product Owner) with the highly specific working world (of the slaves). The computer driver makes the connection between the generic world of the operating system, and the specific details of the hardware. And the database driver makes the connection between the generic world of the programming language, and the specific details of the specific database product.