The madewithlove team dives into their first Between Us session where they discuss problems that they encounter through their daily work. Today’s topic is refactoring. Vinch Battaglia, CTO in residence, is joined by Jonas Drieghe, software engineer, and Dimi Van Lunter, engineering manager, to gain their insights.

Listen to this episode of Pulse, our podcast

First, the team discusses an all-too-common scenario where production has slowed down. The team wants to do a rewrite but is that the correct decision? According to Dimi, that’s often the wrong decision. Jonas points out a definition provided by Martin Fowler which helps set some definitions for the conversation.

To restructure software by applying a series of refactorings without changing its observable behavior. — Martin Fowler

Source: https://martinfowler.com/bliki/DefinitionOfRefactoring.html

Refactoring: where do you start?

On a project, how do you know it is time to rewrite or refactor? When an engineer is raising concerns, have them make a plan. By asking some questions, the entire team can begin a conversation. How big is the scope? What is the benefit to the team? What is the benefit to the product and thus the end-users? Treat it like building a new feature. Determine what the trade-off is for effort versus value.

Bird by bird

As new features are being introduced, there are small pieces of code that need to be changed by engineers before the existing system can have added functionality. This happens every day. This type of refactoring is essential to maintaining the system.

You are usually in debt because you’ve taken a loan. — Jonas Drieghe

Most companies should know that when they are making choices, picking a trade-off, that they have to repay that loan. Otherwise, you will end up with a codebase that is unmaintainable.

The product management team might ask for a faster delivery and when that happens it’s up to engineering to communicate that they need to come back to the code at a later point and clean it up.

Boyscouting

Try and leave this world a little better than you found it. — Robert Baden-Powell, founder of the Scout Movement.

Although it’s important to be constantly improving code, there are times when the code doesn’t need to be perfect. In a startup, there are things constantly changing. Understand the context and what will happen in the future to help make decisions about the code. As you are running an experiment, if it fails, the related code should be removed. When things work, it’s time to think about going back and refactoring so that the product has quality moving forward towards new experiments. By doing many small refactors, you will not have to stop and do a big refactor.

Just testing

How do tests come in to play? It’s important to look at why you are adding them. For normal development work, you want to add failing tests work in a Test Driven Development (TDD) fashion. But when refactoring, you want your test to pass before changing things. Make sure to break the implementation temporarily to ensure that your test is truly valid.

Stable vs speed

It’s difficult to measure the quality of the codebase but you can look at the way it impacts the business. How many support tickets are you receiving? How quickly can new experiments be tested? By starting discussions with your product team, you can make sure that the maintenance of the existing system is simplified where it needs to be. Maybe the scope of difficult feature can be simplified or even removed.

Make it visual

Some managers are likely non-technical so how do you communicate with them? Colin Breck has a system called Quality Views which allows the team to diagram and assign color codes to the components of the system.

By doing this, your CEO will have a better overview of the system. — Dimi Van Lunter

The colors are based on the existing quality across a number of criteria. This can help everyone in the company see which parts of the system need the most attention. Clearing up the communication between the engineering and non-technical parts of a business will lead to a better product.

Listen to the full podcast for more tidbits and interesting points!