Refactoring and Redesign are Different

I’ve been working with people starting their transition to agile. They are all smart people—some of them scary-smart. And some of them are misusing some of the terminology. Some people are using the word “refactoring” to describe significant work, say, weeks or even months of effort of rework. Sorry, I call that redesign.

To me, refactoring is simplification of existing design. It’s something you can complete in a few hours, or, at most, a day. Refactoring could take a day if you need to write some tests to verify you haven’t broken anything.

But if you’re taking several days to a week or more to “refactor,” I don’t think you are refactoring anything. You are redesigning. Redesigning is a useful activity, especially if you have technical debt. But call the activity what it is.

If you have enough technical debt to need redesign, say so. Call the activity redesign. Allow for the time. Explain that you are paying down technical debt. If you’re like me, you might even chunk the redesign into smaller pieces, so you can iterate on the redesign, paying down your technical debt in pieces.

If you’re refactoring, that’s something you can do without needing a ton of extra time. Refactoring is something you should be able to do in the time allowed for the story or the task, because most of the time, refactoring is sufficiently short that it is absorbable into the time for the story. If you see technical debt that is not absorbable, make a card and put it on the backlog, because you need to make the technical debt transparent to the rest of the team, including the project manager, and most especially the product owner or the customer. No matter what, you need to make technical debt transparent to management.

Refactoring and redesign are two different beasts. As a project manager, I want to know when team members are performing which activities. I want to make the choice about refactoring¬† a “yes” by default. I want to be able to make the redesign choice with the product owner or sponsor, because it affects the project cost and schedule and the sponsor needs to have that discussion. Redesign is not a default yes decision. It depends on many variables.

But you can’t have that discussion if all redesign is called refactoring. It’s not. Call the activity what it is. If it’s redesign, call it that. If it’s refactoring, call it that. But don’t call redesign refactoring just because you don’t want to call it redesign or because you think the cool new word for redesign is refactoring.

Redesign is still redesign. Refactoring is simplification, and takes very little time. Make sure you don’t confuse the two. Once you start messing with significant technical debt, watch out. You are likely redesigning, not refactoring.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in project management and tagged , , , , , , . Bookmark the permalink.

4 Responses to Refactoring and Redesign are Different

  1. Sam says:

    So the main difference between refactoring and redesign is just how long you have to work on it?

    I’d rather had expected that refactoring is like cleaning up your workspace after you, while redesign involves moving furniture around. But I am not sure how to translate this to software design yet.

  2. Paulo says:

    Hi Johanna! Thank you for your awesome work and blogs (I’m just loving Create An Adaptable Life btw).

    But I humbly disagree with you on this one. As I come from an IxD background, for me “design” is always about choice: you start with an outside-in approach and make decisions based on how well they are aligned with your vision (from how the product will be used and perceived). So, if you are just cleaning the house and don’t want to affect any external and previously intended behavior, you are refactoring, not redesigning.

    For example, suppose you have in your hands a legacy system and notice that the inefficiency in its spaghetti code base is causing serious performance problems. You may decide to pay the technical debt and refactor it. On another situation, you have a system which was built to support high availability and scalability scenarios, at cost of performance. Then, you suddenly realize that performance was in fact more critical to your business, and is willing to redesign your software and rebalance your tradeoffs.

    But both situations may take months of work…
    What do you think?

  3. Pingback: Project Management Resources, Templates, Books, Tools, News :: PMToolbox | Project Management

  4. Jagadeesh says:

    We(our team) just started transition to agile process. I had strong debate in my self on this topic. Your explanation perfectly fits to my thinking and I am thinking in the same lines. Guess right lines.
    Perfect article that suits to my team situation. Thanks for nice article.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>