One of the risks of incremental development is that we incrementally add complexity to our code so that we gradually let our code base evolve into something that becomes unmanageable over time.
This risk needs to be mitigated by (the art of) refactoring.
Some developers I know seem to consider it a shame to refactor. Apparently it is a sign of weakness because it shows that they didn’t properly implement a feature initially….
IMHO not understanding the importance of refactoring is a sign of lacking agile maturity.
What is refactoring?
Refactoring is the primary process to mitigate the risk described above, by minimizing code complexity. It enables developers to wait to add features until they are needed, and then just add them as easy as if they had just been put into the code base earlier.
Refactoring is one of the primary methods in Lean Software Development to reduce waste in the form of unnecessary source code.
Refactoring isn’t a failure
Refactoring isn’t a failure to ‘Do it right the first time’ as it increases 3 primary aspects of source code:
Change tolerance: Proper refactoring enables developers to more easily add future changes to the source code.
Value: Refactoring avoids the necessity to add features when they aren’t needed yet. It therefore increases the net value of your code base
Longevity: Refactoring keeps your code base simple. It avoids, or at least postpones, the “big rewrite”.
Don’t implement features because you consider yourself a clairvoyant. Help your team members by shouting out the acronym YAGNI whenever you see the urge emerge to implement something that isn’t needed yet, or when you see someone implement a design which is too complex for the current required feature set.
‘You ain’t gonna need it yet!”
I am currently involved in recruiting a role with “minimal agileness”, so I’ll definitately put the concept of refactoring on my list of “things to verify the understanding of”…