After they’ve started using their very first credit card, many young people have a similar reaction when they review their first statement. “Wait a minute. I can pay the full $1,342 right now… or I can just pay $20? Ha! How do these ‘idiots’ stay in business?!”
Eventually, they learn how those ‘idiots’ stay in business.
And although you might not think about it this way, a similar principle is at work behind the scenes every day in the software products you’re managing.
Let’s talk about why you need to build refactoring into your product development process.
What is Software Refactoring?
First, let’s define software refactoring. Actually, we’ll let an authority in this area, author Martin Fowler, define it for us.
From Fowler’s great site, refactoring.com:
“Refactoring is a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”
If done properly, your team will make these small changes to your code base entirely behind the scenes and without any external consequence—meaning they won’t break, slow down, or in any way disrupt the user’s experience with your app.
Which means you should be able to make your refactoring tweaks at any time. And you should. Often. Here’s why.
Why is Refactoring Important?
Let’s return to our credit card metaphor. Yes, paying off the entire balance on your card every month might sting a little when you write that check. But as you know (and as that youngster who chooses instead to make the minimum payment will learn soon enough), the longer you wait to pay off that balance, the more difficult it will be to do.
By regularly making small internal changes to your app—by refactoring—you can keep your product lean and elegant and more easily adaptable to the newer functionality that you’ll want to add to it down the road.
Or, as we like to put it: The benefits of software refactoring compound!
Tweet This:
“The benefits of software refactoring compound—and so will the damage of not refactoring.”
Refactoring Pays off Technical Debt
Technical debt accumulation over time can be risky. That’s why you need to refactor frequently.
Consider a product team that shuns refactoring. Maybe that company’s stakeholders insist on unreasonably short development cycles because they want new product releases out ASAP. So the team makes a conscious decision to focus entirely on new feature development (and maybe an occasional priority-one big fix) and not to do any refactoring along the way.
Because the team isn’t making these minor but important tweaks as they go, the product’s code base becomes increasingly clunky and built on increasingly-outdated (or at least suboptimal) code.
Time passes. The team’s failure to refactor isn’t causing any short-term problems with the product, at least none that users can see. But those problems are building in the background.
Eventually, when the product team wants to make a major upgrade or build a major extension to the product. The code base will be too shaky and unadaptable to the new plans. And at this point, it’ll be too late for refactoring. All of those little changes—which, at the time, might have even seemed too minor to bother with anyway—have compounded into a development problem that’s now too big to fix.
Someone will have to admit, “We’re not going to be able to refactor our way out of this problem. We’re going to have to redesign this thing.”
Actually, it’ll probably sound more like, “#%@&! We’re not going to be able to refactor our way out of this. We’re going to have to @#$& redesign this *&^% thing!”
How to Build Refactoring into Your Product Development Process
First Step: Make regular time on your agenda for refactoring.
Say you have $10,000 saved for home projects, and you decide to use it all to upgrade your kitchen countertops and add a backsplash. Those projects are fun and will make your home much more enjoyable.
But what about the standard home maintenance and updates you also need to pay for? Painting the exterior of the house? Replacing the water heater? Trimming the trees in the backyard?
These fixes and maintenance items aren’t exciting, like your fancy new kitchen will be. But consider the alternative. If you don’t budget for them—if you don’t set aside some of that “home project” money for the ongoing, boring stuff (think of this as home refactoring)—eventually you’ll have a house with a gorgeous kitchen, a busted water heater, and an out-of-control jungle in your backyard.
So build refactoring into your process. Give it budget—time, resources, its own slots on your team’s calendar.
Let’s say you’ve got 400 total developer hours slotted for your next two-week sprint. You might want to set aside some portion of these resources—say, 10%, or 40 developer hours—for refactoring.
Just as automatically putting 10% of your paycheck into a long-term investment can grow your wealth tremendously over time, automating the process of allotting hours on your team’s calendar for refactoring can pay huge dividends in the health and adaptability of your product over the long run.
Next Step: Make sure your stakeholders understand the necessity of refactoring.
If your executive stakeholders are not already sold on the importance of refactoring, it’ll be your job as a product manager to explain its significance.
When you’ve built in a little extra time into your upcoming development cycle for refactoring, and a stakeholder isn’t convinced that those tasks need as many resources as you’ve allotted for them, you can explain that you are investing in the long-term health of your product. That’s what you are doing, after all, because the longer you don’t deal with the minor issues along the way, the more likely they will grow into a major catastrophe.
“If we don’t take a little time to make these small changes as we go,” you can say, “We’ll just be creating debt that we’ll have to pay off eventually—and that repayment number gets bigger every day we don’t address it.”
We recently hosted a webinar on the topic of ‘redesign’ with our friends at Pivotal Tracker and Notion:
Bottom line: If you’re responsible for a software product, refactoring is not a nice-to-have step to include in the development process. It’s an ongoing obligation to the long-term health and viability of your product. If you don’t budget resources for refactoring, you risk racking up technical debt that will be costly to fix later.
