Refactoring, Redesign, Time, and Transparency

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.