Prototyping and Simulation Software

There’s an interesting article making its way around Digg today - Development In the Fast Lane. While there’s some very interesting concepts in the article, several of which I agree, there are a number of blantant errors, or misguidings, which I simply cannot help but point out.

After Citibank’s mortgage division relaunched that retail application in November 2006, IT made just 120 hours of post-production changes, most of them minor. Chandler says that iRise clearly helped: "We’ve taken out paper-based prototyping and manual, text-based requirements, and moved it towards the electronic medium."

Just 120 hours of post-production changes… that’s interesting, but I have to question the validity of those numbers. I know people on Mr. Chandler’s team and they do great work. However, I’m curious if that number of 120 hours is only for the US state-side employees, or if that accounts for time spent on the project by the development team in India. I have my doubts.

Tools like iRise "allow you to build the simulation of what you’re going to get at a really low cost," says Carey Schwaber, an analyst at Forrester Research, who calls poor requirements definition the root cause of bad software. IRise claims that it can cut requirements time in half and cut reworking time by 75 percent, numbers that Schwaber says sound reasonable.

Really low cost? Again, I have to question this. I’ve talked to a number of companies who’ve implemented iRise. It’s not cheap. I’ve been quoted $1.5M - $3M for installations at corporations the size of Citi. My guess is that the Citi installation topped $2.5M. That’s definitely not a low cost by any measure.

I would agree that poor requirements are the root cause of bad software. I just experienced a requirements gathering escapade that took two-and-a-half months, when it could have take less than two weeks if we’d just gotten real and built a prototype, or used some agile methods. So, the cost savings is there in time saved, but I seriously question iRise’s claims of the ability to cut rework time by 75%. Where do they get this from? How did they measure it? Can we see the data behind this claim?

"Paper prototyping is lengthy and it’s not connected to anything else. You prototype it and you throw it away," Chandler says.

Well, paper protoyping isn’t lengthy if it’s done properly. We do paper prototyping pretty regularly. Paper is cheap, real cheap. You can do a lot of paper prototyping for $2.5M. It’s fast, flexible, and cheap. And paper allows you to make changes in mid-stream w/o any need to generate an entirely new prototype and make the participant start over from scratch.

Have you seen the code iRise generates? Microsoft Frontpage is more elegant. To be fair, iRise never claims you can reuse their prototype code. IRise code is thrown out as well.

The article continues on the second page with a great statement from Hanspal from BMO Financial Group.

A simulation tool, on the other hand, can force people to speak the same language, by showing them a model of what they say they want, he says.

Don’t get me wrong, I’m a huge prototyping fan. I’ve experience first hand the advantages of prototyping. There are significant savings in time both from initial development and rework after the fact. And that’s just for standard web interactions. Now, if you consider RIAs and other disruptive technologies, prototyping is essential to the process. Prototypes allow you to show what you mean rather than simply show a few sketches.

The problem I have with iRise is that with a boxed tool like iRise discourage pushing boundaries, breaking molds, trying something new. You’re simply doing the same thing that was done before. There’s no advancement and innovation.