I love it when my readers challenge and question me. Thank you, Sam and Paulo for asking the equivalent of “Huh?” for Refactoring and Redesign are Different. You asked great questions. Let me see if I can answer.
For me, the time issue is the lack of transparency about the time required to complete the work. Refactoring is less time, because it is the simplification of code or tests or requirements or documentation or any other work product associated with the system. Because it is simplification, you can timebox it, and leave the system in a better state than it was before, even if you don't finish all of it.
Here's an example. My office is in a perpetual state of not-quite-cleaned-up. Why? Because I'm a consultant. I have several books in process, so I have research books on my local bookshelf so I can grab them when I write my fieldstones. I have pads of paper and many pens of various colors, so if I do receive a call, I can grab a pen and paper and take notes if a potential client calls. I have headphones so I can use headphones for a skype call. I have yellow folders with my current projects in progress. I don't have a lot of work in progress, but I have projects in progress. I finish chunks of work and get them to a done state, but I often wait for a client to get back to me before I start the next chunk. So I have projects in not-totally-finished states. These projects might be proposals. As a consultant, that's a good thing, not a bad thing.
I hate cleaning up my office. To me, it's a total waste of time. But my office makes Mark crazy. To keep marital bliss, I timebox my office refactoring to an hour or two every month or two, when he starts rolling his eyes, or when even I can't stand the state of my office. That's refactoring. I'm not moving furniture. I'm not redesigning a filing system. I'm simply cleaning up.
But there was one day (or weekend? I can't remember) a number of years ago when I did redesign the location of my desk, tables, filing system. That was either rearchitecture or redesign. Take your pick. That was a total work interruption. I could not get back to work until it was done. I had to complete all of it before I could get back to work.
To me, that's the difference between refactoring and redesign. If you have to stop refactoring, there are many logical stopping points. You finish your “sentence,” your current logical stopping point, make sure you haven't broken anything, and you are done. But with redesign, you have too many balls in the air. You have to keep going to really finish what you've started. When I changed my office, I had to move my desk back, and move all the wires. Well, I have 5 big disks as local backups. So all of them had to move and their wires and power supplies had to move. My ethernet cables had to move. My phone lines had to move. You get the picture. Same thing with software or tests or documentation. You start pulling here and you have to push there when you redesign.
So it's not just the time involved in refactoring; it's the fact that with refactoring, you can stop at almost any time. You can timebox your refactoring time to a small timebox and still be done. But with redesign, using a small timebox, such as an hour is almost impossible. You are almost always committed to days of work because you are tearing things apart and then putting them back together, and that is not a trivial matter. Stopping inside a short timebox is not something you can plan on doing with redesign. If you can, you are lucky.
The problem is if you call it refactoring and it's really redesign, there is no transparency. That lack of transparency leads to a lack of decision-making. The developers make the decisions. Now, developers are very smart people. Like I said, some of these people are of the scary-smart variety. But they may not have the business-side of the smarts. They may be unaware of the business needs. They are making business decisions because they are preventing the business from being able to release because they have decided the health of the code is more important than the release date.
I want transparency, both about technical debt and about business decisions, such as release dates. As much as I like binary decisions, such as release criteria, I want to know why we need to address technical debt. I want to know why we need to release now. I want to know what the tradeoffs are and why we need to tradeoff.
When people call redesign refactoring, the technical decisions are no longer transparent. I am not a fan of technical debt. But I want the transparency around the decision. As a project manager, I don't want someone else to make it for me. Even someone who is scary-smart.
4 thoughts on “Refactoring, Redesign, Time, and Transparency”
Huh? again… Refactoring = changing the design *of a body of code* (in small steps) without altering the behavior.
For an analogy going the other way, from offices to software, I think it’s like “tidying”, not “rearranging” – after Martin Fowler.
“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.”
Thanks to baby steps, you can stop your refactoring any time. However, if you do that, your software may be in left in an intermediate state. Such a state is likely to be less good that what it was. This means you’d incur technical debt if you stopped there. Don’t you think that, once you started a refactoring, you shall not stop until you “gained” something from it? If you stop, you’d better scratch all your changes and start over again another time. That means that you cannot stop any time, as you cannot for a redesign.
Refactoring is something you do continually while programming. It’s part of the work, not a separate act that you need to — or even can — timebox. If you are have to timebox it, it’s not refactoring. It’s cleaning up mess resulting from not completing the work earlier. If you have to timebox “refactoring” that indicates that people are *not* refactoring.
I think your articles about refactoring/redesign touch a very important point. I’m not qualified to discuss what consists a refactoring or redesign, but as a business analysis consultant, I couldn’t agree more with the importance of having transparency about the time required to complete a refactoring/redesign. Business stakeholders must be kept informed of the impact of performing or not these tasks at certain points of the projects, so they can make an informed decision based on the short- and long-term impacts their choice will have on the delivered product.