How to maintain a business partnership about refactoring?

Becoming business partners grants us freedom to refactor. Careful though, we must not over-abuse this trust if we want to maintain this partnership.

Remember my team from the previous post? The one that had managed to build a great business partnership with its sponsors. I did not tell the full story though. After a while, we wanted to see something different and a few developers moved to other teams. Eventually, new devs and a new team lead where brought in. Unfortunately, the team’s practices did not survive the change. Not long after, a few misguided refactoring broke the business partnership.

With great power, comes great responsibility. Uncle Ben

As business partners, we can enjoy freedom to refactor. Maintaining this partnership should be one of our top priorities. Keep on doing what got us in there is the obvious first thing to do. We also need not to over-abuse this trust. Doing unnecessary refactoring is a tremendous trust killer. Here are a few practices to avoid this trap and maintain this business partnership.

This the 15th and last post in a series about how to get sponsorship for large scale refactoring. If you haven’t already, I recommend you start from the beginning.

Kanban-style timeboxing

Timeboxing is a good way to avoid wasting time on refactoring. Unfortunately, timeboxing is always a lot easier said than done. Pausing a refactoring between 2 commits or in the middle of a large find-replace wastes time too! Expanding the time box is not a solution either. It makes both measuring and enforcing the time spent refactoring very tricky. 

Do you remember Rachel Davies talk I mentioned in my previous post? Her team managed to get this right. Their trick was to negotiate a refactoring bandwidth of n developers full time. This has many advantages:

• First, it’s a lot easier to measure the time spent refactoring. That’s great for continuous improvement and trust with business people.
• Second, it involves less task switching. Once we start a refactoring, we don’t stop until it’s done.
• Finally, it’s kanban-style slack time. Under extraordinary deadline, the refactorers can temporarily switch to other more urgent work.

💡 Timeboxing with ‘x team members full time’ is a lot easier to do than with typical time constraints.

Focus on high return on investment refactorings

Obvious, but it’s very easy to waste time on the wrong refactoring. There are a data-driven techniques to stick to the most important refactorings.

💡 Use data to spot the best refactoring to work on.

1. Some tools, like CodeScene show us the hotspots in our codebase. Working on these cannot be a bad move !
2. FIXME XXXX comments is a trick to collaboratively identify the most painful problems. Whenever a developer is bothered by badly designed code, he would add a FIXME comment or a X to an existing one. After a few weeks, the team can simply start by refactoring the FIXME comments with the most stars!
3. Doc Norton suggests tracking 4 metrics to detect if a code base is degrading. As soon as we see these metrics degrade for a section of the code, we should think hard about refactoring it.

I’m done!

I hope these practices will help you to maintain your business partnership. Business partners have great freedom about how to tackle refactoring. If you’ve been in this situation before, you might have come up with innovative practices. Please share them below, I’m sure it will interest a lot of people.

This was the last post in a series about how to get sponsorship for large scale refactoring. I’ve been writing about refactoring for almost 4 months. I’ll be glad to write about something different next week! Don’t worry though, I’m sure I’ll come back to this topic again.

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"!