There was a lot of email discussion about my post on the cost of change curve. A restatement of the problem:

Assume a classic waterfall process. On March 15, you release version 1of your product. On March 20, you start work on version 2. On April20, an urgent change request comes in. Assume two choices:

• make the change in version 1 and release a patch.
• make the change in version 2 and include it in version 2's release.

Let's assume that certain of the work is the same in either case. Youhave to scour version 1's requirements documents, architectural designdocuments, design documents, and code for the implications of thechange. You have to update each of them. (Remember, we are assumingthe kind of project to which the cost-of-change curve applies.) Youhave to make the change and test it.

So why would version 1 have a substantially higher expected cost?

Here's what people came up with:

• In version 1, if the work toward the patch doesn't detect misimplementations, nothing will: you've just delivered a defective patch, which has substantial costs (especially in goodwill). In version 2, mistakes made in the change can be caught at many places along the way to the new release. Another way of putting it is that the cost-of-change curve is largely measuring risk of releasing defects.

• There is some additional work in version 1 (preparing a patch release, special testing of the patch release, keeping track of which customers have which patches, maintaining multiple version control branches, etc).

• In version 2, some of the work can be folded into things you're doing anyway (such as updating requirements documents for other reasons, changing the database schema, running manual test passes, etc).

• Disruptive, interrupting work - "context switching" - costs more than doing work you planned on.

• Money that wasn't budgeted (to make changes in version 1) "costs more" than money that was (to fold changes into version 2).

• Some of the cost of the change is born by people outside the development organization. (They're the ones working with inadequate software while waiting for the patch, they're the ones who may have to relearn things, they have to install the patch, etc.) Even in an imperfect market, some of that cost would presumably be reflected back to the development organization. (Echoes here of Genichi Taguchi's cost of quality curve.) In the case of the version 2 release, the recipient's cost of the change is included in the expected cost of any new release.

• At the end of Version 1, there may have been some cleanup that drives the costs back down (tactical hacks fixed, architecture rejiggered, etc.) Even without that, the team may have gotten some down time to refresh themselves. (That is, they're temporarily out of the trap wherein overwork visibly consumes hours but invisibly destroys efficiency.)

The agile methods are, in large part, about driving these costs down, it seems to me (and to others).

Thanks to Alex Aizikovsky, Laurent Bossavit, Todd Bradley, ClarkeChing, Jeffrey Fredrick, Chris Hulan, Chris McMahon, Glenn Nitschke,Alan Page, Andy Schneider, Shawn Smith, Glenn Vanderburg, RobertWatkins, and perhaps others I forgot to record. Because of theunderwhelming response to my quirky network invitations thing, I'd concluded the 120,000 hits myblog got last month were mostly due to two out-of-control news aggregatorshitting my site once per minute.