This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Flattening the Cost of Change Curve: Theory vs. Practice
Modern languages combined with the engineering practices derived from eXtreme Programming (Test Driven Development, constant refactoring, continuous integration…) make it possible to flatten out the pessimistic exponential “cost of change curve” we learned in the early days.
The ability to *do* this involves learning skills and habits your team may not have yet.
There are a few areas no one’s learned how to flatten the cost of change curve completely, especially post release.
Examples of things Danube has found harder to change (especially post-release):
- database schemas
- APIs others have started depending on
- UIs your users have become accustomed to
- application servers (JBoss, WebSphere, etc.)
- programming languages
These things can (and often should) be changed in the future, but the cost will be higher than a design change in a well-written object oriented program that has automated tests. Perhaps this
shows limitations of our skills as an industry.
(The word ScrumMaster itself is another example. Many of us wish we’d chosen a term like Scrum coach or Scrum facilitator to more clearly convey the ScrumMaster isn’t the team’s boss. But changing the term now would only increase confusion.)
This isn’t an excuse to dwell forever on future-proofing things like the database schema. There’s a reasonable balance point between due diligence and analysis paralysis. You can release a migrator with your next version. Sure there’s some rework, but rework is cheaper than no work.
Download the PDF version: Flattening the Cost of Change Curve blog