I talk a lot about Agile methodologies here on this blog. I do this, not because I am an expert, and not because I am a devout follower. Rather I do it because I find it fascinating.
The promise of Agile is that the traditional cost of change vs time curve can be drastically flattened. This flattening is what makes Agile agile. Does it work? I don't know, but if so, the techniques that help flatten this curve are incredibly valuable, whether used in an Agile framework or not.
Components of Agile
Short Iterations
Short iterations means that you get feedback from the customer early and often. I don't know if this flattens the cost/time curve. However, it does highlight where changes need to be made, early in the process. i.e. Really this is just another way to do requirements gathering that is more likely to be effective in practice.
Refactoring
Accepted wisdom is that it is easier to maintain and extend clean software than hacked together systems. Refactoring is a way of keeping the software clean when you don't have an exhaustive design stage upfront. It also acknowledges the reality that you rarely know everything up front, so your design has to change.
While refactoring seems like a good idea, it doesn't seem to fundamentally change the shape of the cost/time curve.
Automated Unit Tests / Continuous Integration
Quality tests that are run automatically upon new changes can really decrease the odds of introducing new bugs upon changes. This seems like something that really could flatten the cost/time curve. Unfortunately, this seems to be the step which is not often followed through on.
Why not?
Continuous Integration isn't fundamentally that hard. However, it does require being able to make builds in a single step. (Question 2 on The Joel Test) For some reason putting the work into making this happen often takes a lower priority than fixing bugs or implementing new features.
writing good tests is hardOn the other hand, writing good tests is hard. Very hard! I think most of the time it is easier to write the new code than it is to write the tests for the code. Most developers aren't necessarily good at writing and designing tests, even if they are good at designing and writing the system to be tested. And even if you can write good tests it takes time, often more time than it took to write the code being tested.
Do automated unit tests and continuous integration flatten the cost/time curve? Well, it does raise the cost in the present, which has the effect of flattening the curve, but not in a helpful way. It seems like it should make things cheaper in the future as it should catch new bugs as soon as they are written. However, refactoring becomes much more expensive when you have a bunch of unit tests that have to be modified along with the code.
So to answer the question of whether this flattens the cost/time curve, I am going to give it a definite maybe.
Conclusion
There are good ideas in the Agile movement but like all fads, it probably isn't fully worth the hype. Based on examples, it is clear that Agile can work well in the field, at least for certain problems. However, most organizations that say they are adopting Agile only adopt parts of it. Even though many organizations that claim to be Agile are really just trying to buzzword compliant and aren't implementing the right things to gain any benefit, I still think the ideas can be taken piecemeal. They just can't be adopted blindly and expected to work. As someone who doesn't like to just jump into the deep end of the pool, but rather get my feet wet first, I will continue to explore Agile techniques and talk about them here in a hope to understand what works well and why.
