Agile shifts the economics of software development
I often hear this argument about "re-engineering" also known as "refactoring" in Agile circles:
One of the problems with justifying improving code quality ("re-engineering" in this quote) may be one of scale.
Normally (in legacy code and waterfall projects) improving code quality means spending a lot of time going over code that already works and trying to make it more flexible so that some code that does not work (typically a new feature) starts working.
This is hard to justify because of the size of the investment (too much code to "re-write" or at least "improve") and the fact that the outcome is very unclear (we don't know if the code that does not work today will actually work once we have "re-engineered" the legacy/older code).
Agile shifts the economics by putting the emphasis on "re-engineering" the code (actually: refactoring) at every step of the way, not in one massive go!
In Agile projects refactoring is just part of coding, you must refactor every day to improve the code quality and to facilitate the development of new features.
In Agile projects (because of this economic shift) you don't need to justify the refactoring, you do it as part of your daily work, pretty much the same argument can also be used to explain why Test Driven Development is done: it does not cost more, it is just part of coding. By doing it at every step of the way you don't add costs, you actually contribute to higher productivity by doing small improvements that will avoid larger problems in the medium/short term!
If you or one of your managers are stuck on the "there's no justification for re-engineering" camp it maybe because you/them have not yet understood the economics shift that Agile software development brings to software development.
Agile software development (re-factoring and TDD as one example) just simply change the context (do it every day, not when you bump into a wall) and with that they make quality code part of our daily life!
As an example I can quote one of the developers working in my previous team: "I was working in a consulting company and there the pressure was always to deliver more features we had no time to do the things right! Now in this way of working (Scrum with XP practices) I finally can be proud of what I do because I have the possibility to do the things right!"
NOTE: the productivity of that person was higher not lower than in his previous job! ;)
at
11:48
[...] it is difficult to justify work that doesn't bring any added value or whose results cannot be measured to evaluate the _immediate_ outcome.As a software development manager, I've been also on the side of "there's no justification for re-engineering, just implement the feature!", why I've been there (and are not anymore) is that at that time I understood the problem wrongly!
One of the problems with justifying improving code quality ("re-engineering" in this quote) may be one of scale.
Normally (in legacy code and waterfall projects) improving code quality means spending a lot of time going over code that already works and trying to make it more flexible so that some code that does not work (typically a new feature) starts working.
This is hard to justify because of the size of the investment (too much code to "re-write" or at least "improve") and the fact that the outcome is very unclear (we don't know if the code that does not work today will actually work once we have "re-engineered" the legacy/older code).
Agile shifts the economics by putting the emphasis on "re-engineering" the code (actually: refactoring) at every step of the way, not in one massive go!
In Agile projects refactoring is just part of coding, you must refactor every day to improve the code quality and to facilitate the development of new features.
In Agile projects (because of this economic shift) you don't need to justify the refactoring, you do it as part of your daily work, pretty much the same argument can also be used to explain why Test Driven Development is done: it does not cost more, it is just part of coding. By doing it at every step of the way you don't add costs, you actually contribute to higher productivity by doing small improvements that will avoid larger problems in the medium/short term!
If you or one of your managers are stuck on the "there's no justification for re-engineering" camp it maybe because you/them have not yet understood the economics shift that Agile software development brings to software development.
Agile software development (re-factoring and TDD as one example) just simply change the context (do it every day, not when you bump into a wall) and with that they make quality code part of our daily life!
As an example I can quote one of the developers working in my previous team: "I was working in a consulting company and there the pressure was always to deliver more features we had no time to do the things right! Now in this way of working (Scrum with XP practices) I finally can be proud of what I do because I have the possibility to do the things right!"
NOTE: the productivity of that person was higher not lower than in his previous job! ;)
RSS link
2 Comments:
Another factor that enables refactoring to be practical is the availability of tools that support the standard refactoring operations with a click of the mouse. Without such tools, refactoring would be a manual exercise and therefore very time-consuming and error-prone.
By
Anonymous, at April 03, 2006 11:54 PM
Very much true. The Agile manifesto states "People and interactions over processes and tools", but what that actually means is that people should use the tools that suit their needs. And refactoring is an activity that clearly benefits from tools.
Very good point Dave.
By
Unknown, at April 15, 2006 12:17 PM
Post a Comment
<< Home