Wednesday, April 16, 2008

Even if Websphere and RAD were free, they'd be expensive

I was pairing yesterday with a colleague using RAD and the true cost of this tool dawned on me during one of the many times when it froze up for a few minutes. For reasons we could not understand, my partner's computer completely froze for a bit. Not just RAD, but practically the whole computer. We could see through the Task manager that RAD was consuming all of his resources. All my partner did was try to open an XML file. 5 minutes of waste for 2 people to open a file.
It's actually worse than that. Smart people will tell you that the most expensive thing you can do to a development team is to interrupt them and break their concentration. The term context shifting is often used. Context shifts for developers are expensive, the theory goes that developers don't go from zero to full speed instantly, that they need to get into a 'zone' to produce their best code. It often takes about 20 minutes to get into that zone. I agree with this theory. It holds true for me, and every other developer I know has agreed with this theory.
A context shift, or interruption, is actually more expensive than just the time it takes to handle the reason for the interruption. It also costs another 20 minutes of ramp up time.
RAD, has a built in Context switch generator that automatically pulls developers out of their zone. That 5 minute freeze is really a loss of about 25 minutes. That's the real cost of RAD.
Let's put a dollar amount on that. Let's say that it costs $100 an hour to pay for a developer's time and you have 6 freeze ups a day on RAD, each of which cause the developer to work at an average of half speed for 20 minutes, thus producing half the work they would if they hadn't been interrupted.
Each 5 minute freeze up would cost: $8.33 in lost productivity.
Each 20 minute ramp up would cost: $16.66
Each interruption would have a total cost of $25.50
If that happens six times a day you are looking at $153 in wasted productivity.
$153 a day wasted per developer.
$765 a week wasted per developer.
$39780 a year wasted per developer.
I've played a little fast and loose with the numbers, but I believe this is a pretty conservative estimate. Consider the fact that the quality of the code produced by developers is going to suffer, and as a result extra defects will make it to your production environment, you're looking at much higher costs.
For a roughly $5000 per seat tool, you'd think that at the very least it would work well.

No comments: