How to make Refactoring your new habit for 2019

Happy holidays and happy new year! I hope you are spending time with your loved ones and celebrate your accomplishments for 2018! It’s that time of year again — it’s time to make new goals like joining the gym or stick to a new diet! The challenge is having the discipline to keep going to the gym even when you don’t want to, or making healthy choices even when it’s easier to eat the fried chicken in front of you.

In this blog, I’ll help you add new habits that will make YOU become better developer!

As I reflect on 2018, I realize I don’t refactor as often as I should. Maybe this is something that every developer out there struggles with when she determines WHEN is the right time to refactor or whether she SHOULD refactor often. Perhaps your company’s culture values the Source Line of Code (SLOC) metric over refactoring code for long term maintainability. As a result, you might be encouraged to add new lines instead of refactoring existing code. Or, perhaps you might feel that refactoring is a challenging task. It’s so much easier to add new code than changing existing code. If it’s not broken, why fix it?

Granted, there are times when you can skip refactoring, however, skipping it all together is a bad thing! As the codebase grows, refactoring is the key to ensure that we can go fast forever. Even if your company’s culture value SLOC as a metric, you still need to refactor in order to make room for new features. As a developer, it should be part of our responsibilities to leave code in a better state than when we first arrive. This means doing the right thing by cleaning up bad code and refactoring existing code.

Honestly, I sometimes also skip the refactoring part when I do TDD, maybe it’s the timid side of me that is afraid to change existing code, or that I didn’t want to get my hands dirty — it’s too much work! Regardless of the excuses, I am proactively growing my tech debt. When the entire team fails to refactor, the codebase becomes so cluttered that every new feature takes longer and longer to implement, and it will come to a point where it’s so painful that you just avoid touching legacy code all together. It’s also a red flag when the team requires a refactoring story to spend time to refactor existing code. Why do we avoid refactoring so much?

Within a year, a codebase can became more and more difficult to maintain. For us, it got to the point were we started to realize that we have not been doing our due diligence in keeping the codebase clean. Every time we add a new feature to an existing feature, we find duplicated classes in different packages, methods that were “cut and pasted” all over, and slightly varied implementations scattered in different places! How did it get this bad?

How many would admit that you sometimes skip refactoring because writing tests and implementing code was good enough at the time?

This got me thinking, how can I get my team and myself to take that additional 10–15 more minutes to reflect and refactor? The idea hit me. If I can make refactoring as part of my daily habits — like brushing my teeth or eating breakfast every morning, then I won’t think twice about NOT refactoring. It would be a habit that I just do as part of my software development practice.

In “The Power of Habit” book by Charles Duhigg, the author shares numerous case studies of how people change their habits successfully. The key to changing any habit is understanding the habit loop and replacing existing habit with a new habit.

The habit loop consists of:

Here is how you can make refactoring as part of your software development habits.

Notice when you have the habit to skip refactoring or desire to write a new test right after you just got the current test to pass. That might be your cue because you seek the reward of seeing passing tests. Here, we are not trying to eliminate your existing habit of writing tests first, we are adding on a new habit — refactoring to your current routine.

For me, the reward I’m seeking when I move from one test to another is the satisfaction of passing tests and completing the story as soon as possible. Instead of only focusing on speed of implementation, seek the satisfaction of having a cleaner codebase by finding and removing duplicated code and still seeing tests passing.

What does a successful refactor look like? It’s when you have eliminated extra lines of code, simpler and expressive code implementation with existing passing tests, AND your users did not notice any changes to their workflow. If the users noticed that the application’s performance improved, that’s more brownie points for you and your team!

When refactoring: look for duplications, eliminate duplications by following simple design and rely on your tests to ensure you have not change existing behaviors.

One of the ways you can get in trouble is refactoring and changing existing existing features that are outside the scope of the story. Actually, you can get into big trouble for gold plating (adding more features than are needed) and you can negatively impact users’ current workflow.

Recently, my pair and I refactored a filtering feature and we thought it was a great idea to also change the default ordering from creation date to last modified date. Within one day of the release, the users complained that they did not ask for the change in default filtering and it changed their workflow! Oops! But yay for the short user feedback loop!

Under my 2019 Dev Goals, mine says:

When I plan to write the next test, I will refactor existing code because it provides me with the satisfaction of a cleaner codebase and passing test suites.

Here’s my 2019 challenge for you: see if you could make refactoring as part of your software development habits! Please leave a comment and let me know! I want all of us to become better developers!

Happy holiday!

Duhigg, Charles. The Power Of Habit: Why We Do What We Do In Life And Business. New York : Random House, 2012. Print.

Related posts:

My wife is divorcing me after 12 years. I don’t want a divorce. It’s clear she is unhappy about something, but she cannot articulate it and does not have “bandwidth” to talk about it. Even in therapy…