This thread discusses the Content article:
Using Metrics To Help Drive Agile SoftwareUsing metrics to drive agility... I can see using metrics to drive development but I don't know if I would call this agile. Let me explain:
1) Customer value is always at the forefront of (most) agile methods. By using metrics and having them drive, you are doing the refactoring after things get bad. This is backwards.
Before you add a new piece of functionality you look at the design and decide if it needs to be refactored to accomodate the new functionality. If so, you put on your 'refactoring hat', make the design change while keeping the behavior constant, and then put in the new functionality with the new design.
With metrics driving you would put in the new functionality (because the metrics arent bad yet) and then because you put it in with an inadequate design, your metrics warn you, and then you refactor.
2) Constant refactoring, if done in a disciplined manner should keep code 'cleaner' than driving by metrics. Developers have a sense of smell/beauty when it comes to their code. If they are disciplined they should catch problems before they register on the 'ugly' scale of metrics.
3) If disciplined refactoring does not occur then you have a problem that metrics can't really help. You've let the smell get bad enough that it is stinking up the place. I also submit here that most large refactorings are an aggregation of small refactorings that have not been done.
----
So, to sum it up, I can see how this technique can be very useful in traditional methods. But if you are using an agile methodology that affects developers then I think it may be harmful to turn the order of things around.
But of course I could be way off
Amr Elssamadisy
Forums 
