This is the best way to cure the “My program is always right” syndrome. Seeing a real person suffering on the precious work is hard for them. But it will create a better sence for future software development. Less 50 stories high building to redesign when confronted with an extra 50 stories to build.

Coders who care about the quality of their work would be exercising thinking-in-action (if I may borrow from Dewey) and if you asked them to “build a bridge” then “spanning something” and “can be crossed” are implicit and you would get what you asked for.

Telling the same coders that they’re creating an enterprise whatsit is an entirely different story. If nobody has a clear idea of what an enterprise whatsit is then why be surprised when you get a half-working enterprise whosit instead?

Of course, the code is merely a means to an ends. As is the user interface, the graphic design, the copywriting etc. So ultimately it all comes back to satisfying a need, which might be a user need. But this doesn’t need to be user-centred per se, as you could also argue that satisfying the user need is thus fulfilling a business goal. Either way there is a higher purpose.

This is why it’s so important that an undertaking have clear, holistic vision at the top. It’s ok for the bridge builders to place each brick perfectly, but someone needs to make sure the bridge spans the river and can be driven across (did I pass that line Patrick mentioned?).

Much of the time this is not the case. Take most big IT projects, they shouldn’t be an “IT project” at all, just because it involves technology does not make it the responsibility of the IT dept. The project should be business-driven and driven by the business. Otherwise you get the techies spinning their wheels creating beautiful junk.

Sorry, this has strayed from the original conversation a little. So to pull it back on track: yes you should understand the “gravity” before you build but also why you’re building the bridge in the first place! And appoint an overseer that is removed from the brick level construction.

It seems like the hardest thing to change is the user. I don’t think this indicates a need to do all the interaction design up front but I do think it means that understanding the user should probably be the place to start. Those of you with much more design experience than I have would probably have more to say on that.

User Centred Engineering?

Thought you would find this interview between Kent Beck (Extreme Programmer) & Alan Cooper (UX designer) interesting. At one point the anlogy of software development to architecture comes up & interestingly it’s Cooper arguing for the upfront user research/design/”architecture” period to make sure that there isn’t uneccassary rebuilding whereas the programmer wants to get started straight away because “programming gives you information”. It’s a long interview the excerpt below is the relevent bit:

Beck: OK, wait. I agreed with you very close to 100 percent, then you just stepped off the rails. I don’t see why this new specialist has to do his or her job before construction begins?

Cooper: It has to happen first because programming is so hellishly expensive and the cost of programming is like the cost of pulling teeth. I can go have my tooth pulled for about a hundred bucks. OK? But what’s the cost of having your tooth pulled? You don’t have a tooth there. OK? And that’s what’s going on in the world of software. There’s enormous cost in writing code, but the real cost in writing code is that code never dies. If you can think this stuff through before you start pouring the concrete of code, you get significantly better results. You get significantly more efficient programming and you don’t end up with pulled teeth.

Building software isn’t like slapping a shack together; it’s more like building a 50-story office building or a giant dam.

Beck: I think it’s nothing like those. If you build a skyscraper 50 stories high, you can’t decide at that point, oh, we need another 50 stories and go jack it all up and put in a bigger foundation.

Cooper: That’s precisely my point.

Beck: But in the software world, that’s daily business.

Cooper: That’s pissing money away and leaving scar tissue.

Beck: No. I’m going to be the programming fairy for you, Alan. I’m going to give you a process where programming doesn’t hurt like that—where, in fact, it gives you information; it can make your job better, and it doesn’t hurt like that. Now, is it still true that you need to do all of your work before you start?