I'll buy that for $1

I've been doing a bit of digging around this afternoon, looking at what other IA and User experience consultancies have to say about themselves and the work that they do. And I have to say I've been struck by the number of times I've read this: "$1 spent up-front can save $100 fixing the problem later" - or some variation. I must have read this at least seven or eight times this afternoon and it started to irk me after a while.

For those who haven't come across this chestnut from the world of human-computer interaction, in their 1988 book "Principles of software engineering management" T.Gilb wrote: "Once a system is in development, correcting a problem costs 10 times as much as fixing the same problem in design. If the system has been released, it costs 100 times as much relative to fixing it in design."

Now you'll admit that this is a nice, chunky statistic to be able to throw around when someone's questioning whether more time on requirements and solution design is really worth while. And I don't doubt for one minute the underlying truth of the statement - money spent on up-front requirements and design is going to pay for itself many times over before the project's done and dusted.

But the 1:10:100 claim in the context of a Web site development project, and particularly as a means of justifying expenditure on information architecture, strikes me as being the worst kind of specious reasoning. Here's why:

1. Gilb was writing in 1988 and it won't come as a surprise to any of the punters out there that things have changed in the software development world since the book first went to press. Not only are the languages friendlier - if you don't believe me feel free to compare Java or C# to the likes of Pascal, Fortran, C or Cobol - but the development tools, software architectures and deployment environments are (literally) generations ahead of those in use in '88. And that doesn't take into account the fact that the data on which the book was based would, by necessity, have been even older.

2. Compiled languages - and they were all compiled languages in '88 - are generally more difficult to de-bug, correct, test and deploy than the vast majority of scripted languages used in your typical modern-day Web project.

3. Gilb refers to 'problems', not usability issues; not deficiencies in the information structure; not process issues; so the step from Gilb's 'problem' to an IA consultants' usefulness is a long one.

4. Gilb refers to "fixing the same problem in design", which for him didn't mean visual design or information design or even interaction design - it meant everything that doesn't involve actual code being written. So, given the host of 'problems' that might be resolved during 'design', I again fail to see that the next logical step is to bring in the IA consultant.

5. There's no mention of the sort of 'fixing' that's needed. Was it a poorly-defined business rule? Or was the background colour out by a couple of shades?

6. Why should I think that anyone who uses user-centred design can achieve just as big a saving? What have you done to justify the association?

I'm always happy to see people promoting the use of user-centred design techniques for the Web, and the need to prove a return on the investment is a central concern to us all, but there are a lot better examples to use than this one from software engineering, and the logic from service to benefit to engagement will flow a lot better for you if you use research that's closer to home.

Apologies for the soap-box, but we need better discipline in our discipline...

For alternatives, try this nice summation from Aaron Marcus & Associates (NY), written in 2002.