Sometime ago, I was talking to my friend Matt about what would be the 'Cost of Change Curve' of Agile projects without an efficient automated testing strategy. Basically, we were talking about Boehm's Cost of Change Curve.
And Beck's famous flat cost of curve.
The latter, assumes all XP practices are performed efficiently. So the question, how would the curve grow if automated testing was not performed or was not performed efficiently. I don't want to go into much detail about what kind of automated testing (unit, functional). Let's assume the selected strategy doesn't work.
Today, reading a Cockburn's book, I saw the graphic that I was imagining, but with another topic: Agile without refactoring.
This is exactly what I thought. At the beginning it is cheaper not to think about an automated testing strategy. As the project evolves. the cost of changes without having the automated test harness grows exponentially. The analogy with refactoring is perfect. At the beginning, it is possible to do small changes without cleaning the code. A few weeks, after that, the code becomes so messy that it becomes costly or impossible to do the changes.
Hi, I'm Matt.
ReplyDeleteAgile is all about reaction and ability to deal with change. Refactored code (tight code) and code repleat with continuous integration allows the teams to move quickly and be responsive to changes in their environment.
The Speed to Change that Fede talks about here is a measure of confidence in the team. If I have a higher level of confidence in my software, I can move faster and change focus quicker. Confidence in the code and confidence in the system is what is important for successful systems and speedy development.
Thanks for the comment, Matt!!
ReplyDelete