Support Refactoring

I’d like to conclude this series of
blog posts on Seven Strategies for Product Owners with a final strategy that
often gets overlooked on development teams but is vitally important: support refactoring.

Sometimes Product Owners resist the
team’s desire to refactor because they don’t get any new features after
refactoring but often times refactoring is the fastest way to actually get new
features in because a clean codebase is far simpler to work with than a messy
one.

Just think of your kitchen. Is it
easier to make a five-course meal in a messy kitchen or a clean one? This
analogy holds true with code. The cleaner, more straightforward the design is,
the faster it is to make changes to it.

I have had the privilege of working
with some of the top software development teams in the world and I can tell you
that one of the key characteristics of all of them is that they pay attention
to the quality of their code and constantly refactor both in the small and in
the large.

Software developers should be refactoring
in the small all the time and what I mean by that is that as we build a feature,
before we release it we should make sure that it’s supportable. If we’re doing
test-first development, there’s a step in the process to refractor our code.

In test-first development we build
software in three distinct tiny steps by first writing a test for the behavior
that we want to create, and then implementing that behavior to make that test
pass, and finally to refactor the code and the tests to make them supportable.
This includes coming up with good names for the behaviors that we’re building,
introducing design patterns when appropriate, and making our logic clear.

One of the things that I love about
doing test-first development is that I’m constantly paying attention to refactoring
my code and keeping it clean as I move through the red-green-refactor cycle
throughout my day.

But refactoring in the small is not
always enough and every once in a while, I still have to do larger refactoring.
This is in order to, as Ward Cunningham puts it, incorporate our learning back
into the code.

We don’t learn about our system in
tiny increments but rather in chunks and we want to have our code reflect our
understanding of the system. So, every 3 to 6 months or so I end up taking time
to refactor my code and incorporate some of the major learnings that I’ve had
back into the code. Sometimes this happens more frequently, like weekly or even
daily, depending upon how much I’m learning.

But I don’t encourage refactoring
code indiscriminately because we’re far too busy for that. My criterion for refactoring
code is typically when I have to go back into it in order to do something with
it, such as extending it or fixing a bug. At those times it makes sense to
clean my code up before starting to dig in and tear it apart to make it do
something that it didn’t do before. This is when I find refactoring most
valuable and also most cost-effective.

Scrum has the Golden Triangle of
the Product Owner, the ScrumMaster, and the team. The Product Owner is an
advocate for the product. The ScrumMaster is an advocate for the team and the
health of the team. The team and the Product Owner must be advocates for the
health of the product itself and part of the products health involves regular refactoring.
Everything else in the known universe requires maintenance so why shouldn’t
software?

Note: This blog post is based on a
section in my book, Beyond Legacy Code: Nine Practices to Extend the
Life (and Value) of Your Software called Seven Strategies for Product
Owners.