The High Cost of Emergent Design/Subsequent Refactorings

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.

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.

About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in .net, agile,, c#, cio, cto, software architecture, wpf, xp and tagged , , , , , , , , , , . Bookmark the permalink.

6 Responses to The High Cost of Emergent Design/Subsequent Refactorings

  1. Alan Dayley says:

    Interesting post.

    In my opinion your first list of four points describe a dysfunctional use of Scrum, XP, any Agile and any other development process. Constant refactoring is an big flag that something is wrong, whether in Scrum, XP or traditional frameworks.

    It is common for engineers in any environment to be rushed to ship and have their expertise in architecture ignored. I think it is a disservice to “blame” Scrum and XP for a problem that is a common failing in any software engineering environment. If the Product Owner or (Project Manager or Director or VP or Customer) will not allow the engineer experts to apply the needed architecture work, technical debt, as you describe, will happen.

    This, however, does not justify the opposite problem of extreme design up front that will not meet the customers needs even if completed correctly to specification.

    Balance is needed. Trust the developers to do the work right. Allow them to deliver value often in iterations that are complete and well architected. Include architecture work in the product as you go. The balance will be different from product to product and team to team. Find it, and Agile will work very well! I like your list of remedy points. These would fit well for any framework, including Scrum and XP.

    • PostAgilist says:

      Hi Alan

      In terms of balance being needed, yes, certainly 🙂 That was covered in my (seminal) post on that topic

      My more recent posts go into more specifics.

      I don’t think it’s a disservice to “Blame Scrum or XP” in this case I find it quite appropriate.

      You are saying “Constant” refactoring is a big red flag — and I would agree — however “Constant” refactoring is encouraged in the XP literature. Whether they call it “constant” or “merciless” they believe in the notion of ongoing, constant refactorings, and use unit tests and “pairing” to try to shake off some of the ramifications of that.

      In a Waterfall world, one wouldn’t have to battle constantly, every sprint, with the Product Owner/Manager etc to schedule doing some (more) architecture. That would have been built into the plan and front loaded.

      It’s a much more difficult task to schedule in a Scrum/XP world, since it must be done periodically and constantly. In an XP world it’s even more difficult because their YAGNI approach makes them even less willing to put in the requisite architecture.

      It is perfectly fair to hold the Scrum/etc processes accountable for their shortcomings.

      People try to hold “Waterfall” accountable for it’s short comings all the time. It’s more than fair to hold Scrum and XP just as accountable.

      Nothing is without consequence; things that Scrum/etc do that “help” in some areas also “hurt” in others. To cast light on that is part of my reason for blogging about this subject in the first place.

      My first four points describe a typical “Scrum Team” whether or not it’s dysfunctional. It may well be! But given that it takes 2+ years (or more) to shake out “dysfunction” we can all rest assured that most Scrum teams, will, in practice, be dysfunctional.

      Yes more design up front is necessary, and it’s something that is rarely (if ever) talked about or taught – at least not by the Agile, Inc., crowd.

      Also whether or not the refactoring is “constant” it will certainly be more frequent in whatever system uses less up front planning and architecture.

      Whether a BDUF or MDUF approach creates software that does not meet the customer needs is a red herring.

      I don’t think that a cacophony of FUD should be used to try to scare people into using impractically short iterations, where “practical” depends on the nature of the application. I find “Scare Tactics” such as “if you don’t do _insert_your_favorite_must_have_practice_here your project will fail!” used almost constantly by CSM’s, etc. These sorts of unfounded scare tactics need to go away and be replaced by cogent arguments based on fact and reason.

      In particular I think “delivering new releases” every 2 weeks makes little sense, since by definition little planning could go into such a release, and what little time was left even if it did occur would result in little in the way of new features that customers would actually notice.

      I’m glad you like my list of remedy points


      • Alan Dayley says:

        I have been part of Scrum teams creating complex hardware and firmware products. In specific one product had a small team that eventually grew into three teams. The architecture of the product was kept well in mind while running the delivery of results in two week sprints. Two key actions helped do this:

        – Two members of the teams were product architects. They interacted with all other members of the team throughout the sprint to help guide story implementation in line with architecture needs.

        – The teams planned at least on “Tech Talk” per sprint to describe and review parts of the architecture. Engineers working on new parts of the architecture or complicated areas would present the block diagrams or other documentation about these areas of the product, how they work or are intended to work and so on. Some sprints saw two of these talks, depending on questions that were coming up or needed spread of information.

        A third action that should go without saying but is not part of many projects is that the architects also worked closely with the Product Owner to ensure market needs were reconciled against technical needs.

        This was not a perfect project, nor a perfect world. The architecture of the product did get the attention it deserved while the teams continued to work for “Done” every sprint. It can be done.

      • PostAgilist says:

        That’s great that you were able to do that.

        It is essential to do enough planning and architecture and that is part of the reason for this post.

        I never said that one needs a perfect world or a perfect project.

        I merely demonstrated that there is a “high” cost associated with refactoring, and the less upfront design one has, the higher that cost will be.

        The fact that something “can” be done doesn’t mean that it often “is” done.

        Waterfall can be enhanced to accomodate change better, and less structured methods can be enhanced to accomodate architecture better.

        Also it helps that despite using the Scrum framework, you had a Product Owner that was accomodating to architectural sprints.

        That certainly helped in your success here but it’s not realistic to extrapolate from that that every Product Owner is that savvy, but perhaps they will learn that that is essential.


      • skeptic says:

        @PA: Great article and I do like that you always seem very articulate in backing up your blog posts in the comments.

        @Alan: You didn’t mention how mature the product/architecture already was while implementing scrum. For example, If you were to implement an ERP solution for a customer on a highly customizable, existing ERP system with scrum, it might be a great approach. However, if you were building that ERP system from the ground up, you might have a problem with your standard two week sprints. I know this is not the case in theory, but it usually seems to be the case in reality. The problem is simply that building solid, flexible architectures is a hard task and takes a lot of thought and foresight. The actual work required does not always take a manager, a product owner, and a scrum master, and so on. Many times I see management claiming success in their scrum teams only because, behind the scenes (not as part of their scrum process), there were talented architects/developers that built a solid foundation.

  2. Pingback: My recently “disappeared” comments regarding PMI and Scrum | PostAgilist's Software Architecture Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s