Why the conventional wisdom on refactoring is bunk

Refactoring is about slowing down so you can speed up.

Refactoring is essentially re-engineering a piece of code. You take a chunk of your codebase, either a module or large slabs, and rewrite it from scratch.

Refactoring is a dirty word in the startup space. It’s never at the top of list of requests from sales or customers so most organizations don’t want to invest time or money into it. But refactoring is our modus operandi at Yellowfin.

We’ve been refactoring from Day 1

We’ve really embraced refactoring and see it as part and parcel of what we do. Our development team have the autonomy to decide what and when to refactor under the covers. From a UI perspective, we also continuously integrate and iterate modules to improve their usability.

In 14 years, I don’t think a quarter has gone by where a developer at Yellowfin hasn’t taken a piece of our codebase apart. That’s because Yellowfin was built on a foundation of continuous improvement.

“Refactoring is an ethos that applies to our whole business.

Refactoring slows us down so we can speed up

I recall talking to the Head of Engineering at a customer of ours, who was criticizing developers who want to refactor the codebase. It was an interesting conversation because we have the opposite perspective, and are willing to iterate our software all the time by refactoring.

It comes down to our overall approach – our software is a journey. We’re open and critical of our own software because we want it to be the best. So we’re continually improving what we have to make it work better.

At our heart and soul, Yellowfin is an engineering business. We want to develop the best product in world so we continually work on the same module over and over again to refine and improve it. At this level, refactoring is not about making cosmetic changes, more we’re working on the underlying base to make it faster, smoother, and more integrated with the rest of the product.

Over the life of a product this has a huge impact. Over time we’ve added new features and functionality but the product itself also works so much better because we’ve continued to refactor it.

Bandages don’t fix long-term problems

Startups are continuously told not to refactor because their primary objective is to get their product to market. But constantly putting bandages over a problem, rather than investing in getting it right, will eventually result in it falling apart. Often the investment will go towards other things, like support or consulting, rather than improving the underlying product. This is fundamentally flawed because the root cause is always in the product.

By going back to the root cause you can usually see that a lot of the additional expenses being spent on support, for example, are because you just don’t have the best product. Spending money on getting your product right is a wise investment. It also reduces expenses elsewhere in the business. You can have a very lean support and implementation team. This then allows you to scale in other ways that you wouldn’t otherwise have been able to.

The benefit of hindsight makes us faster and better

Refactoring gives us the opportunity to look at our product differently. When you add new features, software can easily become really complicated and harder to fix or debug.

By refactoring, we get the opportunity to step back and think about how we would develop a module from scratch with the benefit of hindsight. We’re currently doing this for dashboards and storyboards; we’re throwing the old codebase away and re-imagining what it needs to do. The result will be something that is much cleaner for our developers, something that is easier to debug and test, while also being a superior product for our customers.

I’ve got a strong view that refactoring isn’t something that developers or management should be afraid of. If done well, it positions a business better over the long term – you won’t start losing customers because the technology is old or clunky. By chipping away at your codebase regularly, taking on a module or two at a time, you take your customers along for the ride with you. It’s a much better result than simply waiting for your customers to decide they’ve invested in the wrong platform.