In my previous post, I demonstrated that even with a lowered cost of change curve, change is still expensive.
But, you might say, OK, we agree with that, so we’ll try to do more up front analysis and try to keep customer changes to the minimum necessary…that will fix the problem.
Not so fast…
If you are using a “traditional” process you might be OK.
But if you are using Scrum or XP or a close variant of that, you have another issue to contend with.
Constant Refactorings mean constant changes. Why do you have so many refactorings when using a Scrum or XP process?
1) Since each feature must be built and unit tested in one day, and these features are sprung on the team in increments of 2 weeks, little if any thought is given to any overall architecture — there just isn’t time to do it
2) Since the system is viewed as a collection of features, (often labeled “business value”), and new features are constantly requested on strict timelines, all too often, little over all thought is given to the overall system design.
3) The “Product Owner” will constantly request new features, (see #2), and will rarely if ever schedule the necessary overall architecture of the system until and only when the lack of architecture has broken down to the point that no new features can be added until the system is rearchitected.
Some people are chuckling at #3 because they know it is true…. However this represents a complete blocking of progress for perhaps months… Short term success can be costly when major overhauls are needed down the road.
4) Depending on the management structure, the Product Owner may have ultimate authority over the project and the developers can become powerless to schedule the architecting it so badly needs
Thus, if one is following a Scrum/XP process, especially if you unit testing and thus need to modify the unit tests as well, all these refactorings cost huge amounts of time, and actually limit the number of features that can be delivered.
Eg, if you spent less time refactoring, you could spend more time delivering “business value.”
So how can we do that?
1) Plan and Architect more, as much as appropriate and when necessary
2) Group related features into an overall architecture before executing on any of them
3) Checking in code every day is not the measure of all things.
4) Think more – Do less
5) Don’t fall into a regimented trap of an over scripted, canned methodology such as Scrum and XP
6) Match your work effort to your deliverable effort. Fixed time iterations (“Sprints”) are often not the best approach to avoid the constant cost of refactorings.
7) A software package is not a collection of features. It is an engineered system. To perform well, an engineered system must be engineered. It can not simply be a collection of parts that were assembled and reworked over and over until it became something. At least, it won’t be relaible or maintainable if that approach is overused.