The tale

It was the best of times; it was the worst of times. The thick metadata fog lifted into a bright sunny day of calm and peace, and the land of Software Engineering was buzzing into life again. As the morning sprang from its long sleep, so did I, opened the windows and breathed a heavy sigh of relief.

It wasn't that long ago I had walked down littered alleys and dirty roads. Never had I been so hungry as I was walking the streets of Metadata City. It used to be a promising place, you know; nice clean abstractions and good clear labels on every door, road, trunk, box and tub, but all of that changed as more and more people expanded and exploited those plans. It could have been a wonderful box of chocolates with a simple label 'Chocolate' on it, but people soon started this whole 'Sjokolade' / 'brand' / 'I like white not brown' / 'small bits of cocoa powder mixed with milk and caking agents, having different flavours including caramel, truffles, marsipan, liqurish and brandy, sometimes with filling' labelling all over, and noone could agree on the best label.

My hunger was for clean, straight-up metadata. I had seen the idea as a bright shining lighthouse on the infoglut horizon, and I wanted to find my way to that glimmering place of 'simple and elegant means of finding what I wanted.' I know now that ideas are king, while the joker is ... well, us. No matter how good a plan, it takes only one simple glitch to render it useless. I am such a fool.

There were a few wise men and women that sometimes got together to discuss these problems, but as committees went, they went the way committees usually go; against the grain of the intended purpose. They said 'Strict Standards!', and as people started using those standards it became quite apparent how those standards didn't work or even worked together. It became the hotch-potch stew that we know Metadata City to be today.

But things are changing. People have started taking things into their own hands. Strict standards are being replaced by human and loose standards. Since we can't agree on the best label, why not accept them all? I drifted into a recap of old snapshots ...

Snapshot!

In the old days, software programs were developed by the snapshot mentality. A specification is a formalisation of a given set of requirements that tries very hard to be a roadmap for developing a specific program. It of course can't be right, but since we all think in todo-list terms, it's the best we've got, and we do it repeatedly so that at least some of our attempts works out good enough to be called success. The fact that most fail doesn't seem to pursuade us away from the comforting thought that it "works well enough."

A specification is a snapshot. It is an attempt to freeze time. "Now! Nobody move! This is our specification, and we will build a system based on these needs! Quick; write everything down, and make sure we all agree to it!" And off they go thinking they've got it down pat. Then time and life goes on, everything changes, and the finished product ain't what they want now. This is known as scope creep, but I dare say that that is a misguided label; it is the wrong approach alltogether. Isn't it funny that there is a progrom in the world that states; "The only constant is change." And isn't it funny why don't we embrace it?

The only constant is change

There is some ultimate truth to this; things change all the time, be it systems, people, societies, needs, wants and desires. The latest onslaught of so-called 'social software' really taps into this paradigm; if you design your software for change, embracing it, then there may not be a need to change it when the change comes. Let's see an example;

Someone designs and develops an online store. It uses a specific database and a specific framework written in a specific language. It has specific requirements, such as viewing, selecting and purchasing items, and then handle the communication between customer and seller, let's say email and fax, using a creditcard such as VISA and American Express.

Now what happens if the customer wants to call? Or use a credit card not listed? Or something else changes, as they will do over time? What happens? Well, the people in charge lay out some new requirements, pass these on to the developer, who develops the new feature, rolls it out, and everybody's happy ... provided the customer hangs around for that long and hasn't gone to your competitor that does support whatever feature you needed.

Note that I said needed, not wanted; there are many things in this life we want, but to do certain things you need certain things to do that. For instance, to buy something with a VISA credit card, you need a VISA credit card. It doesn't matter that you have a Fumbles Daily Credit card at all. Pretty self explanatory really, but traditionally we haven't designed systems with this in mind. Instead, we used to say "to use this online shop, you need to have a VISA or an American Express credit card." And that's the flaw; it is us telling people how to use our system, instead of them telling us how they'd like to use our system.

Back to Metadata City and social software; the thing here is that it isn't software telling the users what standard to use and exactly how to use it, it is the users who are free to use the software they would like to use it. It isn't a fixed specification of an idea, but a loose concept of a tool. We're going from specific to abstract tools, daring to trust their users to use it outside a given specified way.

Metadata is reaching that same thing these days. In Topic maps we speak of fixed points of reference, of persistant identifiers, but the new Topic maps standards are taking a more flexible turn, saying that the identity of something is a process more than an ID badge. In the RDF and Semantic Web world, the fuzziness of what a resource really are may have - and I think quite unintentional - pushed them in the same direction. More and more systems out there are starting to understand this very progrom;

As the world is fuzzy, design for fuzzy.

Basically, we must design for change, with change in mind, changing the mindset of our changing world. Anything else is a costly legacy hog that will be costly, painful, wasteful and outright stupid.

Permalink (Fri, 22 September 2004 13:00:00 GMT)| Comments (2) | Opinions Topic maps Knowledge and information