Refactoring is one of the practices that characterizes agile development. It’s defined as the continuous process of restructuring source code, without changing its external behaviour, with the purpose of increasing readability, architecture and future extensibility.

Without refactoring, your solution will not have the appropriate architecture to guarantee long term maintainability.

The need for refactoring primarily arises in the following situations:

• New user stories force the team to rethink their initial design
• The surfacing of undesired side-effects of the code already written (e.g. performance problems)

Any agile team will therefore have to spend a certain amount of time to refactor its code.

In orde to keep on delivering valuable product increments, the team will have to spend just enough time on refactoring existing code:

• too much refactoring will reduce the amount of time available for new developments
• Not enough refactoring will result in design challenges in the long run

There needs to be a balance between the amount of new requirements being implemented and the amount of refactoring, which is depicted in the following image:

This picture shows the relationship between Value — Design Quality — Cost.

For the sake of this exercise we assume that the costs will not change, so we’ll not add time or resources to the project.

“X” marks the spot where a minimum amount of refactoring to guarantee a minimal acceptable design, and a minimum amount of acceptable value by the realisation of new requirements meet. If you want to keep one of these two variables fixed at the minimum acceptable amount, but want to increae the other one, increasing costs is the only way to achieve this.

The primary risk of using scrum (or any other agile methodology) in combination with larger projects, is that you keep on refactoring endlessly, without producing enough incremental end-user value. The primary reason for this is a poor design and the solution is properly scaling the requirements of the project.

In the next article, I’ll briefly discuss 3 practices that will support the scaling of requirements in agile projects.

Stefan Luyten

For more information: http://www.triton-consulting.be