I had to rant a bit today; experienced too much stupidity for one day, really.

Some people say that usable methods are fine and well in commercial, small and controlled environments but won't work in larger places, and especially not in goverment places. Rubbish; the only ones who hold such beliefs are people who haven't got the guts to try them out. C'mon folks, it ain't all that hard, in fact it is a bit like eating a finer meal; chew smaller chunks at one time, test the ingrediants for the right flavours, spit out if it's foul, or swallow if it tastes good. Then go for that next bit that looks tasty and small enough for proper indulgement. This is not something that's guided by the decor of a place or how many is seated around you, nor how much they earn or their religious belief.

But this fear of things sane and normal and closer to human behaviour of course has its causes and origins. Normal traditional development is equalled to a trip to the local burger bar, and it will have roughly the same health benefits to your organisation. Fast and in big amounts will make you feel filled up and somewhat satisfied right here and now; the plate is empty, and you've got a feeling in your belly that all is well. We've done it like this for years, and what we did back then should fit us fine still, because it works. Any change to this routine will only cause an upset stomache.

But is it good for you in the long run? And was it really all that tasty? And is your stomache really all that well anyways?

Eating healthy

It is funny that in so many things in life we're acustomed to the idea of "eating healthy does good for your body" but it has rarely been applied to the development of software. The slogan "anything that gets the job done" seems to be thrown around more often than anything else, which in all it short-sightedness is pushed because of one factor; money. Because time is money. Because if something takes X time to create, it means it costs X to do so. That's all fine and well, apart from the fact that Time to Market becomes the quality factor, not a factor comtrolled by a different quality meassure like stability, usability, accessibility or sensibility.

I don't get (as in, I really get it, but the answer is so stupid I can't believe we're doing it) the short-sighted way to think about money that we apply. Who hire these idiots who think that "anything that gets the job done" actually means we should do things fast and big, the burger bar way?

It doesn't make sense. We can look into any other profession and have a look at what "anything that gets the job done" means there; building a glory box for mum is done with a good idea of its use. Building a house is done on a sound foundation. Building a car is done with a sound skeleton and clever engineering. Building computers is done with sound and complex electronics. Building a plane ... well, you get the idea; the joke "if we built X the way we build software ..." is in fact far more frightening than what we care to admit, which, I think, is the very reason it still isn't dealt with properly.

The age of tools

For a long time now we've built tools to do better software development, but the better the tools we make doesn't equal to better software in the end. Why? Is it because we still need to refine and improve the tools, or - and here is a bit of shocking news to a lot of people - do we need to refine and improve the people using the tools? The very reason I'm bringing up tools here is that there seems to be a rule in the industry that to do good software we need good tools. I'd like to call this bluff.

It is not about tools; it is about people and ideas. The hammer does not build a house. The blue-prints doesn't build the car. Electrcity doesn't run the computer. People do. People come up with ideas, and use tools in trying to realise the ideas. Especially good people. Crap in, crap out. This universal progrom is strong. It is truth.

Methodologies

Which brings me on to one of my most ranting subjects; methodologies. Each and every one I've ever been in close contact with (and trust me; I've seem a fair chunk of them) share one thing that to me renders them unusable; catering to idiots and pedantics. Instead of good people doing a good job and bad people doing a bad job (in which case it makes it easy to train them or fire them) we invent methodologies in which good people will do a mediocre job and bad people can do a mediocre job as well (so that they all rate euqally mediocre, and none gets fired or hired). It is the praise of the mediocre ideal.

Throw them out, and start using your heads. It only takes a project manager to think "Who's actually going to use this system?" and simply ask these people some balanced questions. It only takes a business analysis to think "Why is this bit important?" and simply ask the users if it really is. It only takes a software engineer to think "Why are we doing things this way?" and simply ask the users if they think it sounds reasonable. All in all, it doesn't take much at all. The methodology is not to have a bunch of points from 1 to 100 of things you need to do in a given order; it is about using common sense, and having a set of people that can work with change in mind instead of against it.

Change management

What is so darn hard about change?

People don't like it.

No, that is not true; someone sitting in prison being tortured wouldn't mind the change of freedom at all, so that's not it. Try harder; what sits at the core of the fear of change?

Hard to change.

Well, this is kind of true in itself, but doesn't really cut to the core of the problem. Sure, some things can be hard to change, but why? Why is it that huge organisations are hard to change?

Rules and procedures.

Ah, now you're talking. Yes, there are rules in place, and they must be followed. Procedures must be followed. Processes must be done. Methods must be used. And changing all of these rules and regulations seems like a massive task; we've spent ages putting them in place, and surely it would take another age to change them, and this in turn sounds costly, using a lot of efforts, and at the end of the day, what if there is no improvement? What if we do something wrong? We need a reminder of why those rules put in there to begin with;

To make sure we all work better together.

Only by some misaligned idea of what "better together" really means. Most of the time, rules are put in place to stop a) idiots from doing something stupid, or b) bad people from doing bad things. That also mean that most people who's hired in a position who are good (and I think I can safely assume that to be in majority) will be forced to do below their ability. We're back to methodologies.

Climbing walls; making it matter

Climbing over that huge wall of change-fear is a tricky one for people with no idea of how to do it, or for people with not enough guts to pull it off. It is not really a fear of change; it is a fear of how the organisation will react to the change. It doesn't matter - in some special definition of "doesn't matter" - that your results are better when the branch-head down the corridor fumes over not receiving the right 104-33 form with all the fields in "section 45 : prerequisit accounts" filled out correctly from you. But here's the thing;

It matters. And it should matter not only to your boss or your droids, but to the users. Because, at the end of it all, down that long line from idea to actual product, you the user matter. It seems a lot of people have forgotten this fact. Now go forth and fix that icky misconception; it isn't that hard.

Permalink (Tue, 24 May 2005 13:00:00 GMT)| Comments (0) | Interface and interaction design