If it works, fix it! – Refactoring Is Always Worth It
If it works, fix it! – Refactoring Is Always Worth It
Code refactoring, the restructuring of functional code without adding new features, is quite challenging for many product development organizations. People in charge of prioritizing tasks are often skeptical about the idea of spending days or weeks on altering existing code as they would rather spend the resources on creating new features.
Refactoring Makes Work Easier
Of course, what these people have in mind is what is best for the company: new features have more to offer to the customers. In any case, software developers should remember and inform others about the benefits of code refactoring.
Anyone can write code that the computer can understand. Skilled developers create code that people can understand.
Which usually takes more time, writing new code or reading the old code?
I have one question for you: which usually takes more time, writing new code or reading the old code? My opinion is that on average, developers spend dramatically more time on reading existing code than on writing new code. If the existing code was more readable and understandable, how much more efficiently could developers write new code?
Readability is merely one of the motivations for refactoring. Refactoring can also lead to improved performance, faster bug fixes and changes as well as improved robustness, just to name a few advantages.
When Eating an Elephant, Take One Bite at a Time
In my experience, refactoring is not done enough (actually, I feel a bit guilty because I was often the one to make the prioritizing decisions). What would be the easiest way for organizations to ensure sufficient refactoring and detect the cases where refactoring is particularly necessary?
The best way to refactor is by
- taking small bites
- regularly.
Change the Structure First to Simplify Creating New Features!
I will give you an example: if a story requires an added feature, you might discover that adding this feature is difficult due to the structure of the code. THIS would be the right time for code refactoring. In other words, you should refactor the code first to make adding new features easier, and only then add the new feature. When the team estimates a story, they should not just quickly estimate the story in story points but also think about how it should be carried out. If a need for code refactoring arises, it should be included in the effort for the story. This is a good way to start continuous refactoring. This is how the large product development organizations do it. It also helps organizations to avoid big refactoring problems after a few years.
Keep a Most Wanted List
One of our teams would use the phrase “Class written by God” since no one else was able to understand it.
Another way of including refactoring on the to-do list is to keep a list of the worst outlaw classes which just HAVE TO be redone. One of our teams would use the phrase “Class written by God” since no one else was able to understand it. These parts of the software should be recognized and listed. I encourage teams to keep a to-do list for refactoring in Confluence, for example.
Scare Your Bosses
Now that you have created the list, you will need to sell it to the product management and the Product Owner. You can approach this from two angles: scare them or explain the benefits. One of the benefits could be that creating critical features would become much easier after refactoring. To scare them, you could describe the horrors they will face if parts of the code are not refactored. The boogeyman will come at night and eat their babies, or the neighbor’s pet guinea pig will chew the cables of their Porsche into tiny ribbons. Well, not literally of course.
The purpose is to paint a realistic picture of what will happen in the future if a certain part of the code is not refactored at that moment. Otherwise, they might keep postponing it until the moment comes when making changes becomes slower and slower, and work becomes less and less efficient. We can all imagine that this kind of situation is not ideal for working.
Do It or Die
If you neglect refactoring altogether, you cannot succeed in the product development business in the future.
The purpose of refactoring is to improve the readability and changeability of the code. This, in turn, results in faster changes and more completed tasks. This creates a positive cycle, and everybody wins. If you neglect refactoring altogether, you cannot succeed in the product development business in the future. The holy book of refactoring, Martin Fowler’s “Refactoring: Improving the Design of Existing Code”, is a book that every team should have at their disposal. Especially the first fifty pages are a must-read for every software developer.
Contribyte is the leading product development assistant in Finland. We provide a variety of services for developing your organization!
Arto Kiiskinen
Senior Consultant
In his career, Arto has worked in product development as a Product Owner, Scrum Master and Product Development Manager. The operating methods of both large and small companies have become familiar. Arto loves to improve organizational learning and product owner know-how, and write blogs on different topics. Because retrospectives are one of Arto’s favorite topics, some of his customers have given him the nickname “Retroman”. During his free time, Arto tries to live healthy, buy as many cars as possible, rewatch the Star Gate series and study to become a Personal Trainer. Arto has also written the book “OWN IT – 8 Simple Secrets of Product Owner Success”.
