• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

“Refactoring” is not a Feature

Recently, I attended a luncheon with a diverse group of people in the IT industry–coders, program managers, product managers, business analysts, and architects.  The topic of the luncheon is not important, but at one point the conversation veered towards managing a product backlog, and how to prioritize items in the backlog.  Two of the engineers in the crowd mentioned “refactoring” as an item that might go in the product backlog.

For those who don’t know, “refactoring” essentially is cleaning up an existing code base to enable changes to be made more efficiently, or to improve the performance of the existing system.  Refactoring usually involves restructuring or rewriting portions of code which are convoluted, difficult to understand, poorly documented or unnecessarily complex.  Refactoring, the engineers argued, is essential to add future features, so developers should be given time to “refactor” existing code– even if it is the only activity in that sprint or release.

Sorry, but I have to call B.S. here. Refactoring- standing on it’s own- adds no value, so it is not a feature, and should not be added to a product backlog. As a product manager, how am I supposed to sell a release which includes no new functionality, but has refactored code? Why would anyone want to buy such an upgrade? What does refactoring that provides no visible changes offer to a user? If it doesn’t add any business value, it isn’t worth doing.

Let me pause my rant for a moment to mention that developers who typically fight for periods of refactoring are usually the best developers on a team. They can’t stand seeing inefficient, messy, unmaintainable spaghetti code. I understand and appreciate their frustrations. There may be a secondary value to allowing refactoring to make it into release–to keep your developers happy, sane, and from leaving for greener pastures and that mythical software company where all code is documented meticulously and written as elegantly as possible. Besides that purely secondary value, I argue that refactoring is not worth doing as its own feature for the following reasons:

  1. It doesn’t accomplish a business goal:  The goal of a software company is to sell working software. Refactoring doesn’t allow me to sell more software, unless there is something (an additional feature) I need to add to the software that requires refactoring.
  2. It obscures the “real” problem that is trying to be solved with refactoring:  I’m hesitant to devote an entire sprint/release to “refactoring”, because as a user I don’t know what problems that will solve for me. If you tell me I can’t add the features in the next sprint because the code base is munged, then account for the time you have to “unmunge” (yes I just made up that word) the code into your estimate. Otherwise, what you’re doing is gold-plating, and unnecessary to delivering value.
  3. There is no traceability between “refactoring” and any discernible feature:  This is related to the above points, but if I can’t trace what you’re refactoring to a requirement, then it’s gold-plating. There might be activities a development team needs to do in order to fulfill a requirement or fix a defect (e.g., “improve page response time to 2 seconds”), but those activities should trace to a requirement (has someone even asked that the page response be improved by 2 seconds? And if so, why?) You can’t predict every feature I’m going to ask for as a product manager, so you might be unnecessarily refactoring portions of the code base.
  4. Your work might be thrown away tomorrow:  Suppose I relented and allowed the development team 3 months to refactor a messy code base, without adding new value/features. The following month, the CTO decides to change the platform completely and start (mostly) from scratch, perhaps for good reasons. Meanwhile, my users are stuck with a release that included refactored code instead of some valuable features until the new version on the new platform is released.

I want to reiterate that I don’t think that refactoring should never be done; only that it should never be done in a vacuum without any relationship to business value, solving a business problem, or satisfying a requirement. Hopefully, that will lead to fewer conversations about general refactoring, and more conversations about giving developers time to perform some housekeeping that delivers specific value linked to a requirement of the software.

7 Responses to “Refactoring” is not a Feature

  1. Scott May 1, 2013 at 10:57 pm #

    I completely agree with you about resisting the urge to put superfluous / gold-plating / time-sucking activities into the backlog.

    I also agree that it tends to be the best developers who want to refactor stuff, and that as a general principle, they “clean as they go,” incorporating that into the delivery of “other stuff” – either explicitly baking it into the estimate or just getting it done on the fly.

    However, there are reasons to do refactoring – and I believe those _reasons_ should be evaluated and ranked (for value) relative to other investments being considered in the backlog for prioritization.

    I like how Geoffrey Moore frames innovation investments as being investments to help you either differentiate (your product, relative to competitors), neutralize (a competitor’s advantage), or optimize (your ability to compete). It is inside the “optimize” bucket that refactoring should live.

    If you’re “improving page load time” – that’s not refactoring, that’s meeting a (new) non-functional requirement, something that can be measured in the performance of the product. If you’re “increasing the capacity of the team to deliver in the future” – that is refactoring. Maybe you’re writing code that replaces an existing manually created database schema with one that is programmatically created, such that it can be rolled back. You’re not changing how the product works, but you are changing how the team will work in the future. Maybe you’re taking a mega-class and breaking it up into several atomic classes (OO-design refactoring), which will allow you to reduce the risk of breaking existing functionality when adding new functionality later.

    You do these (types of) things to make the team more effective – optimizing your ability to deliver in the future. Those types of conversations are certainly worth having, and can be had with stakeholders too, not just developers.

  2. Igor May 21, 2013 at 4:45 pm #

    Check out “The Goal” from E. Goldrat. If refactoring is targeted to address “THE GOAL” (i.e. increasing the throughput of the system without increasing inventory towards increase in sails) then you have NO RIGHT to prevent the development organization to make that call.
    This is the problem with the PO/PM – they have no visibility and understanding and they are in no capacity to make general proclamations of what you’ve suggested here. This is why they HAVE to be present during the dev meetings and collaborate. They should have an EQUAL voice with the rest members of the team.
    So – be very careful when you’re talking about something where developers with experience know more.
    Ask their advice and understand the implications.
    Make the joint decision and be ready to pay the technical dept, which, in fact, you HAVE to start measuring.
    When you can compare the PRICE of the debt with the price of the new upcoming feature – then you’ll be in a great position to compare and make informed decisions.

  3. Robin Goldsmith July 9, 2013 at 8:21 am #

    You can win a lot more often when you get to make all the rules. Agile has declared ‘refactoring’ is a virtue by denying and obscuring that it is what other methodologies get slammed for as ‘rework.’ True agility attends to more than a single timeboxed data point and balances a small amount of (often not even additional) effort to do it right the first time rather than needing extra non-value-adding effort to get it where it should and could have been all along with a more appropriate mindset.

  4. Mike July 9, 2013 at 11:13 am #

    Do you also avoid taking your car to a mechanic for routine maintenance since it adds nothing to the driving experience?

  5. Jason July 9, 2013 at 12:53 pm #

    Let’s say this is legacy code that the current dev team had no part in and they now own it. I can see how you’d want to clean it up in that instance. If the current team is responsible for implementing the code that they want to refactor then I’d take a look at the design practices of that team.
    If they’re doing some sort of Test Driven Development then refactoring is just part of the process (red > green > refactor/clean) and most code stank should be cleaned up as the story/feature is implemented and tested.

    It’d be interesting to know the design practices of the folks that asked for a whole sprint to refactor, and what circumstances they feel merit such a request.

  6. Mark / Sr. PM & Sr. BA July 10, 2013 at 12:53 pm #

    I have to agree with the archtiects/Dev leads. Re-factoring is *very* important if you want a stable code-based to build New Features. In our AGILE world, too many projects deliver unstable code that either does not (a) have adequate error management, (b) services in the correct or most efficient layer, (c) performance issues. I have seen this on *every* project I have been on – and I have seen it directly impact New Features. Trying to ignore re-factoring as a significant task in the project is guaranteeing major problems later – and slippage and cost overruns when you need them the least! Not to mention extremely dissastisfied business stakeholders (product owners.)
    The best compromise is to -as part of planning – allocate 20-25% of effort for every release (after the 2nd releast) for Re-factoring. What does the cleint/business get? Stable Code and Less Disappointment with deal-breaking performance problems. Also – there are some new features, and most defects – that are directly affected by the crappy code that Needs to be refactoring. I have NEVER seen developers or architects “Gold-Plate” a system by re-factoring – that is a PM and BA mis-conception (esp. by people who have never been in a development role).
    Also – I endorse one or two releases to be dedicated to “stabilization” to resolve the backlog of serious defects caused by infrastructure or archtiecture issues. Believe me – your clients/business stakeholders will thank you for cleaning up the mess!

Trackbacks/Pingbacks

  1. Scheduling Things Better - Bryce Hanscomb - May 9, 2015

    […] Instead of trying to convince your team that the codebase is close to collapsing and they need to ‘start cleaning up their code’, institute an allotted time each week specifically for refactoring and make sure it gets done–just be prepared to defend your business case for needing to refactor. […]

Leave a Reply

Your email address will not be published. Required fields are marked *