Refactoring Is Not Bad, Until It Is – InApps Technology 2022

Raygun sponsored this article.

When to stop making changes to a working codebase is one of the most ignored problems in the industry. Great developers will continue to push for different levels of refactoring. They insist that refactoring will increase readability, decrease the difficulty of implementing new features, and make the system less prone to software errors. And that’s all true. But do product leaders and developers truly understand the risk of refactoring a working product? Do they understand that choosing to do nothing may be the best decision for the business?

Today, we’ll talk about the deeper reasons behind why great developers want to refactor, even when it isn’t a good idea. We’ll also discuss why refactoring may be needlessly risky for your business. Once you’re armed with this knowledge, you’ll be able to make decisions that make both your developers and your customers happy.

The Developer Need to Refactor

Refactoring is usually rooted in good intentions. A developer believes that with a little refactoring here and a few new libraries there, work will get done much more quickly and everyone will be happier working in the codebase. A less common and more selfish reason that developers refactor is that they believe the code will always be bad unless they wrote it. But in each of these scenarios, the cause of a refactor is the same: they’re unfamiliar with the codebase, and a refactor will make it more familiar to them.

What’s new in the software development business seems to change every month. Developers, particularly the great ones, want to play with the latest and greatest so they can stay on top of their craft. Whether it’s switching from an SOA (Service-Oriented Architecture) to a microservice architecture or using the latest version of the .NET framework, the solution is the same. Refactor the app to use the cool new thing.

When is refactoring not the wise route? Let’s discuss when you shouldn’t go down that path, as well as some alternative, revenue-generating tasks developers can focus on. In other words, not all refactoring is bad.

If It’s a Stable Product, Don’t Touch it

If you don’t see areas to grow that product line, making application changes is not only incredibly risky but also offers no return on investment (ROI) — and with significant opportunity costs. In terms of risk, an architecture change has to go absolutely perfectly to avoid regression bugs that affect users. If users aren’t complaining about issues and you introduce changes that cause issues, you have a customer service nightmare on your hands. You took a risk on an architectural change that affected your customers but offered them no benefit in return. The team might say that with a robust automated testing suite, they can mitigate the risk of regression bugs. But no one ever has 100 percent test coverage or fully understands all of the creative ways that customers may be using their product.

The bottom line in this business is that if your product is working, customers are paying, and you’re not introducing new features, then re-architecting should be very low on your list of priorities.

Don’t Rebuild; Build the Right Things

Developers are some of the most valuable and therefore expensive members on a product team. It makes sense to have your most valuable team members work on features that offer the highest probability of growing the business. A great side benefit of this is that when working on new features, the developer desire to rewrite everything goes away. They get to develop new features that are in alignment with the business strategy, and they also get to build them the right way.

At its core, re-architecting a stable system doesn’t do anything for your business. There are times where it’s appropriate, but it’s highly likely that development capacity should be spent elsewhere for better potential ROI.

The Right Point in the Product Life Cycle

There are situations where a new architecture or major refactoring is justifiable from a business standpoint. Consider the following scenarios:

• The application is able to increase revenue with new features;
• You’ve outgrown your MVP.

In these cases, the developer itch to refactor will help your business.

A product in its growth phase can accelerate that growth with additional features. That’s assuming that these features have been validated by potential customers — or even better, a customer is paying you to develop it. A new architecture or refactoring for new features may make sense, with a few caveats. First, the new architecture must give you some tangible benefit other than “it’s better.” It could be that the changes allow for the completion of a feature in a third of the time. Maybe it minimizes developer onboarding costs. Or perhaps it cuts down application programming interface (API) response times by a certain percentage. Either way, using application monitoring software such as Raygun will help you be able to pinpoint key problems with your existing application and will also help you make a data-driven decision on what to refactor.

Even with new development, refactoring into a new architecture is risky. It shouldn’t be the default for new work. If you decide that the changes would have an adequate ROI, you still must make sure that your new architecture doesn’t break existing features and is able to be done iteratively. It’s not an open invitation for the team to rewrite the entire app. Rather, it’s an opportunity to lift and shift the architecture into what they believe is the ideal one for the future of the application.

Conclusion: Bringing it Back to Developers

Product managers and executives have a great opportunity to align developers with the growth needs of the business. This gives developers the chance to introduce new architectures in a safe way. In this way, when production managers and developers are on the same page, needlessly making changes to a working application is not an issue. It’s about building new things or reconfiguring existing architectures in the right way customers will pay for. If refactoring helps improve existing or new code, then, by all means, the developer should have the freedom to make that choice. And as mentioned above, refactoring just for its own sake makes no sense.

Feature image via Pixabay.