Feb. 18, 2016

Making Time for Refactoring

When we refactor in small increments as we develop code, we’re able to spend a few minutes at a time keeping our code at a high level of quality

One of the most common things I hear about refactoring is that there isn’t enough time for it. I hear that there is important refactoring to the code and architecture that will take days or weeks and there’s no time to fit that in because of tight timetables.

Often times teams write off refactoring as something other teams with more time get to do, but not them. The truth is all teams have tight timetables for delivering their software and the key to refactoring is not more relaxed deadlines (deadlines do need to be realistic, but that’s another topic).

A quote attributed to Aristotle tell us: We are what we repeatedly do. Excellence, then, is not an act but a habit.

The same is true for great coding and, by inference, refactoring. To effectively make refactoring part of our development process, it must not be a large effort that we spend days or weeks on, but rather, a habit that we practice continuously while writing code. So, if we want to make refactoring a habit, that raises an important question.

When Should We Refactor?

Always! When we refactor in small increments as we develop code, we’re able to spend a few minutes at a time keeping our code at a high level of quality. Let’s look at the TDD (Test-Driven Development) cycle to see how it integrates refactoring.

TDD (Test-Driven Development) cycle

In test-driven development, there’s a spot after every time you’ve successfully written a segment of code to evaluate the code and refactor it. In practice, most times you look at your code and you’re happy with it or there’s a small refactor, like extracting a method, which takes a minute or two of your time. On rare occasions, a significant refactoring becomes apparent and takes up 20 – 30 minutes of your time. After each code refactor, you run your tests again to make sure you didn’t break anything.

Another often forgotten trick is to use the automated tools at your disposal. Most IDEs have refactoring facilities built in nowadays. Learning how to use them correctly will save a lot of time and reduce the risk of errors. Knowing what change to make is still essential.

Does this save you any time in refactoring compared to doing a large effort after several months? No, I don’t think it does. In fact, I think you’ll spend more time refactoring. That’s because when you spend a few minutes at a time, it’s easy to absorb that time into the development process. It’s just part of what it takes to get the work done right. When you wait, you’ll probably spend less time because you won’t do all the refactoring that should be done. If you’re like many teams, you won’t do much refactoring at all. Waiting makes you feel like you have to settle for low-quality code. The team isn’t proud of the work and the business isn’t really happy with the results, but they feel like they’re stuck with it unless they pay a large ransom of technical debt to refactor it.

Building blocks

What About Refactoring Legacy Code?

Sure, we’ve all been in that situation where we’ve been handed a pile of code that isn’t up to our (or in fact anybody’s) standards for good code, but refactoring it would take forever. Perhaps it’s mission critical too, or written by somebody who just can’t be questioned. What do we do with it?

First, we have to acknowledge something: people always try to do their best, but circumstances can prevent them from doing a proper job. That code was probably written by people who were capable of better, but rushed through and didn’t take time to refactor because of tight deadlines. So that leads us to step 1:

Step 1: Break the Bad Habit

You can’t change what was done to the code before it got to you, but you can stop it from getting worse. As a team, agree that from here on, no code changes are made without building in time to refactor. Each time you open a file, leave it just a little cleaner than you found it.

Step 2: Set Expectations

You’ve inherited all of the problems with the code and just because it’s been given to you doesn’t mean it’ll magically get better. Make sure there’s an understanding between your team and the business stakeholders about what improvements they need and when they need them. Some things may be able to wait until they come up naturally. Others may be causing customer pain and need attention right away. These items should get worked into your backlog so they can be given appropriate priority and it’s clear what business value they are delivering.

Step 3: Isolate Your Effort

You can’t fix a huge amount of code all at once. As you need to make changes, isolate a particular behavior that you’re testing. Wrap it in tests, and refactor what you’re changing. Sometimes this is as simple as identifying a class or two where the changes occur and focusing effort there. Other times you have to put some work into isolating code.

How we work with legacy code can be very complex and is far too involved to solve in a blog post. Luckily, a very good book has been written on the subject: Working Effectively with Legacy Code by Michael C. Feathers (Prentice Hall, 2004) rightly belongs in the bookshelf of every coder.

Summary

In short, there is no silver bullet for refactoring code, but good practices will take you closer to the goal day by day. Make an effort to refactor every time you are about to close a source file and take the time to diligently chew down legacy code into smaller pieces. Always implement automated testing on the module level or higher to give you a safety net that guards against changes in the behavior of the component and learn to use the automated tools at your disposal.

 

Photo by Holger Zscheyge

Image of daniellynn

Daniel Lynn

Agile Coach
blog comments powered by Disqus
Image of daniellynn

Daniel Lynn

Agile Coach

Latest Posts

Scrumtisch September 2019

The Berlin Scrum User Group meets on September 30th at agile42, Gruenberger Str. 54, 10245 Berlin.

Image of aballer

Alexandra Baller

agile42 Team Assistant

The Scrum Master as an organizational multi-function pocket knife

The Scrum Master is a jack of all trades with a magic problem-solving knife in his back pocket or a master of Scrum?


Image of elrich.faul

Elrich Faul

I’m passionate about helping the current and next generations to develop the skills they need to be successful in a rapidly changing world. I believe that by leveraging my expertise in engineering, psychology and management I can empower individuals and teams to reach their maximum potential. I’m inspired when given the opportunity to coach teams as well as individuals toward growth and happiness.

Campaigning for Dave

agile42 coach Dave Sharrock is running for Scrum Alliance Member Elected Director and we support his candidacy!

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Talking agility at Agile Islands conference

Pascal Papathemelis and the agile42 team will be present at the Agile Islands 2019 conference in the Åland Islands

Image of pascal

Pascal Papathemelis

Pascal has worked as an agile project manager/scrum master/facilitator of various developments in size and type for almost two decades. His focus is on people and practical approaches in order to deliver value. Currently Pascal is working at agile42 as an agile coach on a journey to help organisations and individuals grow, improve and become more efficient in a sustainable way.

Coaching at the Nordic Business Forum in Helsinki

Giuseppe De Simone will represent the Scrum Alliance at Nordic Business Forum in Helsinki, October 9-10 providing agile conversations to attendees

Image of giuseppe.desimone

Giuseppe De Simone

Giuseppe De Simone is a Certified Scrum Trainer (CST), Certified Enterprise Coach (CEC) and Certified Team Coach (CTC), passionate about helping individuals, teams and organizations become more productive by embracing Agile values, principles and practices. He is one of very few to be accredited from the Scrum Alliance as an educator of the Certified Agile Leadership and Path to CSP programs.