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

Sometimes being a usability guy can be a bit straining on one's sanity, especially since most of the business world as we know it think usability is something about a pretty user interface. And this usability guy also happens to enjoy small iterative development steps, somewhat agile programming styles, and a fetish for change.

Change

With any organisation comes a fear of change; fear of something new, fear of something they don't master, and the fear to move forward or backwards without sufficient control. But of course, with all that control (or want for control of that which they don't know) in place we're pretty much standing still. Change comes usually through individual push from people who just do things (often acommidated by 'That's it! I've had it!') , and not as much through memos and policy documents, even though the board might think their changes are radical.

My whole life I've been one of those who embrace change, always tinkering and changing stuff, trying to find better ways of doing things. It hasn't been easy; what I thought was natural to us all seems to be unnatural for most. The holistic viewer is rare. Too many castles, too many counties and countries, too little planet and far too little universe.

It is said that things change best by taking baby-steps. I'd rather say you need to take large baby-steps.

Time

Estimating how long a piece of string is, is one of those things most people get wrong. So, I don't do that. You see, a while back I discovered that the more important the project, the bigger it was and the more cast in iron things were (from specs to time-lines), the more spectaculary it would fail. I'm sure you've noticed too. I'm sure we've all been in a fair number of them.

One way I deal with this problem is to break the problem up into smaller bits and user-test each bit, so instead of trying to pull off 10 things in the span of 10 months and give it a big test a week before it's supposed to be ready, I do 1 thing per month, test that part and take it from there. Seasoned project managers tend to hate my way, because it is hard to measure by text-book project management books and methodologies, and people have a tendency to think they think holistically about problem-solving. But what they actually think is far too often far from the truth.

If the plan is to have 10 things done in the span of a 10 month project, what usually happens? We break them down into sizeable chunks, assigns the subtasks, and try to manage it so that in 10 months we get what we said we would get. If we're late or early, this can easily be seen in project plans and reports, and all is well in the world, because this is the theory.

Along comes real-life; we're three months into the projects, and programmer A with part Z tries to plug his part into programmer B's fancy XY framework, and fails miserably. Communication hasn't been bad, and they've all written buckets of programming style guides and written JavaDoc and technical documentation. And yet the bits didn't fit. This only marks the beginning of the failures of the project, and when you're 20 months overtime you've got a half-baked compromised and limping version of some idea that by this time ain't no longer what you want.

Teamwork

So what should have happened? Well, let's pretend we've got 5 developers and 10 tasks to finish over 10 months. The text-book would state to give each developer 2 tasks. And the answer is of course 'no'; try sitting your 5 developers down to solve one problem. And not one problem each; everybody solve the same one problem. Once that's been solved, you can happily move on to the next problem, because here is what you've got through the process; a finished and tested part, ready to be built on.

Some think that this approach wastes a lot of time for some of developers that could be well spent on other problems, but you see, this is the part where their claimed holistic thinking clearly is flawed; individuals can't be holistic in isolation. No matter how much you try to create a middle layer of communications, nothing beats hands-on experience. Nothing. And if you get everyone up to speed on the one thing, they don't need to be told what that thing is during the next step.

Some say that even this way of doing it is flawed, because they can spend 3 months on getting that one thing right. The answer is obvious; if your developers can't pull off one good thing in time, how do you think they'll fare in multiple things? And also consider how you plan these things; if it indeed takes three months, you've done a bad job of breaking the problem down, my friend. There is nothing wrong with calling a part of your system for an API, or a widget, or an application, or a service. Break it all down into looser reusable bits, because not only is it more managable but project 2 and 3 can now simply reuse that service or API or widget, build on them, extend them, and also strengthen project 1. That's being holistic; break things apart, and put it back together again in clever ways.

Your team

Ok, so everybody needs to be on the same level, and sure, a HTML markup guy won't understand all the geeky finesses the hardcore Java developer does, but here's the thing; if the Java developer can't explain it so that the other person do understand it, it is a failed part. I don't care if you think it is so darn clever and I'm so stupid; at some point, others must understand, and if the lowest common denominator can't understand it (to some satisfactory level of 'understanding') then start again (or, in extreme cases, get rid of that developer; you're not creating a hot apple pie with bad apples, are you?). Tweak it until everybody is on the same level of understanding, because - and here is another important thing - you might be wrong. How about that.

Yes, a big part of usable thinking is to test the darn thing all the time; developers, project managers, business owners and - perhaps somewhat shocking and unusual to some - the actual users. And we do this because the business requirements might be dumb or wrong, and they need to change. Embrace change, change is good. If we don't embrace change, we'll go back to our text-book project at the fifth month when a business case change and we need to change not only all the parts that's affected, but all future plans and prospects as well. This last bit is vital in creating great systems; don't plan for something that might not be a great outcome.

Testing

Doing test cases for our software development seems to be paramount these days; we create test cases, and we develop software that solves the problems described in the test cases until they're solving all of them.

Why hasn't this approach been embraced in other places? When a business owner writes down a business requirement and pass them off as a systems requirement, why isn't this tested? Cross-checking with the sponsors and project management isn't good enough; you need to tap into your users and pull those wisdomteeth out; does this business requirement even affect what the user want? Very often you'll hear in usability tests 'all I really wanted to do is ...' It would have been far cheaper to hear that statement before the business ideas became business requirements than close to release date.

Look to a lot of the big boys of software development these days; they release alpha software for people to play with, beta versions for people to test, and give away parts of their core tools because, in time, it will come back and help them far better than any closed "it will be a big surprise!" plan will ever get you. It is all about testing; testing for bugs, testing for features, testing the interface, testing the market, and, some times, testing the sanity of the business owners; they just might be wrong. Imagine that.

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

An interesting interview with Andrew B. King over at Digital Web Magazine that speak about web-page optimization; why it is important, where you do it, and the psychology involved from a users perspective. A good interview highlighting many of the same things I say about accessibility and methods of web development. A nice read.

Permalink (Fri, 16 May 2003 13:00:00 GMT)| Comments (0) | Interface and interaction design Methodology

The purpose of this article is to a) give people - like project managers, sales, customers and other developers - an insight into what a web user interface developer does and doesn't, shoulds and shouldn'ts, and b) give web user interface developers insight into methods, best-practices and decisions me and my colleagues at bekk not found. do every day.

Permalink (Mon, 28 Apr 2003 13:00:00 GMT)| Comments (1) | Interface and interaction design Project management Programming Methodology