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.
Previous Post: « Remove Dependencies
Next Post: Why Practice 2: Build in Small Batches »