When theory and reality collide
Reality wins. Every time. Theory is our name for how we hope it works. I used to keep a sign over my desk that read “When theory and reality collide, reality wins”. I used it to keep my focus on the reality that we create tools for other people to use.
We all like to think we’re open-minded. The problem is, we each see a lack of it in others, but seldom in ourselves. Now I think there are many reasons besides ignorance for this. One observation I have about myself, and many other experienced programmers, is that we consider ourselves more likely to be correct about technical issues that most everyone else to whom we talk. We don’t consider it ego – it’s our actual experience. The problem is: it’s only true for a very limited problem domain.
What we need is a way to suppress our conceptual immune system – our automatic reaction to defend any point of view to which we have “bought in”. This is especially likely to occur when we deal with others who have their defenses set at DefCon1. If we are talking to a non-technical manager who feels the need to maintain his authority, our objectivity becomes toast.
One reality we have all dealt with is that at the end of the day, we are the ones who have to make it work. In this sense, we are engineers. Reality matters. We’ve each learned the hard way that when presented with a bad design, we will be the ones to take the fall. So if, as Alan Cooper says, the “Inmates are Running the Asylum”, it’s because someone has to.
Now this book is probably the least pleasant book I have ever read, because Mr. Cooper’s persona for a programmer is a caricature of an antisocial nerd. But I read it, and I recommend it. Sometimes we need a dose of unpleasant medicine. That’s not to say that I agree with all, (or even most), of what he says, but that I think he has many points worth thinking about. Just ignore his return to the “waterfall” model, and imagine what happens if you put interaction design people inside the product design feedback loop.
The most essential part of making a negative-feedback system (in the engineering sense of the term) work, is the ability to accurately measure difference between the present and the desired state. If our programs are going to evolve in an organic sense, we must suppress our certainty, based on years of experience, with a willingness to listen to those who will use our programs on a daily basis.
Notice I mention the users – not the managers, sales people, marketing people, or others. They all have valuable contributions, if we will listen without judgment. But nothing can make a program succeed if the people using it don’t actually like it. These are the people who most often get left out of the design process.
I have two suggestions: Get some of your toughest clients and some of the least experienced ones, and discuss the design issues with them. I use a BBS for this, And I’ve found that customers willingly give their time if they feel you are actually listening. Then, get these people in an alpha-test loop (don’t wait for beta).
The second is to attend conferences that are not “new-product” or “new toys” in nature. Now I’ve been to a lot of these things, and eaten an awful lot of awful meals. But the one I keep returning to, year after year, is COFES – The Congress On The Future of Engineering Software. The joy of COFES is that there are so many really accomplished individuals, great thinkers, and people who honestly spend their mental lives “out of the box”, that there’s no more chance of not listening than there is of a child refusing to go to Disneyland.
This entry (Permalink) was posted
on Thursday, October 1st, 2009 at 5:54 pm and is filed under Uncategorized.
You can follow any responses to this entry through the RSS 2.0
feed.
Both comments and pings are currently closed.