Presenting a large scale refactoring as a business opportunity

Have you ever tried to talk about refactoring with business people ? Most of the time, the matter is pushed aside or received with rolling eyes … A few weeks ago, someone on Hacker News asked the question “As a CTO, what is your most frustrating problem with technical debt?”. Here is the most voted answer

I think a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than understand”. (The rest of the time is the same but they’ve understood it enough to think it’s a disaster area.)

I have found it’s best to not take tech debt complaints very seriously and instead look at actual success metrics. For example if every change to a bit of code introduces new bugs then that might be a reason to tidy it up.

ghiculescu

We need a constructive dialogue with business people to get sponsorship for important large scale refactorings. Let’s see what we can do to have one. This is the 10th post of a series about how to get sponsorship for large scale refactoring. If you haven’t start by the beginning.

Presenting a business opportunity

We must be very careful about how we present refactorings. We don’t want them to be seen as unnecessary chores, or the latest tech fashion to follow. These don’t bring value, and business people will run away from such refactorings. Instead, we should present business opportunities for higher productivity to invest in.

Presenting a similar success story and its impact on the business

Most of our companies have been through similar refactorings in the past. We can try to find a successful one and draw parallels to forecast benefits for the business. If the company is too young to have any or they were all failures, we can have a look in the whole industry. When I was at Devoxx in Paris, Hervé Lourdin the CTO of VideDressing presented how they managed to do a large scale refactoring. Among other things, he went over how he managed to get sponsorship from his board. If you understand French, have a look at the full talk. In this case as in most, a likely promise of reduction in the costs of bugs and new features is what made the point.

💡 In most cases, a likely promise of reduction in the costs of bugs and new features is what gets a refactoring prioritized.

Be a Badass Developer

I wrote a lot about being a badass developer earlier in this series. This is when it becomes crucial. Being badass is a way to gain the trust of business people. Without this trust business people will react like the guy on Hacker News. Badass developers are way better at presenting large scale refactoring as business opportunities.

Find a path to do incremental delivery

Without incremental delivery, a refactoring risks delaying features for an unknown time. That scares the hell out of business people. Day to day incremental refactoring best practices will save the day here. They’ll actually help 3 times !

1. To already perform a lot of refactoring in day to day work
2. To learn how to find an incremental refactoring path to present to business people
3. To prove that we know what we are talking about : we’ve already been doing it for a while

If you haven’t, have a look at the articles about incremental refactoring techniques that I wrote earlier in this series.

Pitch It !

In “corporate” environments, building credibility is a lot about being convincing. The more we learn to be convincing, the more likely we are to have our refactoring prioritized. If you are ready to spend some time learning how to pitch, I recommend reading Pitch Anything. At least have a look at its summary. It contains many actionnable nuggets to deliver powerful pitches. Here are a few.

When we present an idea, we should put “frames” (time, authority …) in place to gain control of the discussion. For example, a time frame is a kind of deadline that will urge people to take action now. (Before overthinking it …) 

We should create tension by alternating phases where we are giving and phases where we take a step back. Following the same idea, it also mentions the Tao of Steve to rule at negotiations :

• Don’t want anything
• Show that you are really good
• Leave at the crucible moment

Giving a great pitch is a great way to present large scale refactorings as business opportunities.

💡 Pitching is a great skill for developers to get sponsorship for a refactoring.

More to come

This was the 10th post in a series about how to get sponsorship for large scale refactoring. In next week’s post, I’ll go over how to use a recent discovery about how our brain works to become even more convincing !

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!