Refactoring: Understand the Value

Simple examples to help understand the business value

Typically…

A Feature X has been once developed. It works well, actually, it works flawlessly.

One day, the development team raises a hand and tells that there is a possibility to improve the source code of this very feature. The team says it would make the code easier to be maintained, would slightly optimize the system performance and in the future, less effort would be necessary to invest to develop other features related to this particular one. Better code readability could also prevent mistakes (= defects) in future development. It would remove possible inefficiencies in a codebase and help to prevent technical debt.

Team asks the Product Owner (PO) if it’s possible to create a user story focused on refactoring Feature X. It would be estimated by the team, prioritized by PO and eventually pulled-into the development flow.

“You want me to pay twice for one feature!”

So far everything goes smooth, but then PO states that she actually doesn’t understand the need for it. The message she gets is that it seems to her the development team originally implemented the Feature X in the wrong way and now needs to fix it. Typically, “You want me to pay twice for one feature!” kind of emails tend to pop up in the inbox.

Now, stay calm 😉. The PO has all the right to think of it this way, there’s nothing wrong with it. Based on the same set of information, she just understood it differently — it happens all the time, e.g. at school every student consumes the same input yet not everyone gets Descartes’ Dualism for the first time (though Mr. Descartes naturally considered the distinction between mind and body as absolutely straightforward).

Your goal is now to harmonize everyone’s perspectives on this subject — and examples are very helpful techniques to do this.

Below, you can find three simple examples on which you can metaphorically demonstrate the purpose of refactoring in your current situation.

Examples

The House

You are a civil engineer and you have built a house. The house looks very nice and has built-in all the fancy things that the owner wanted. After few years, the owner calls you saying he wants a huge water tank to be placed in the attic — he wants to harvest rainwater 💧 and use it as an alternative water supply source to help conserve the groundwater. Now, the tank would fit the attic, that’s fine, but the problem would be with the ceiling. It was not designed to handle such a heavy load.

Basically, we have two options lying ahead:

Option A

We will invest in a reinforcement of the ceiling by adding more armature to it. This approach will cost some time and money, but the house’s appearance, floor plan, and all fancy things will remain unchanged while for the future the ceiling will be able to handle any number of water tanks in the attic.

Option B

We will support the ceiling from below using wooden pillars. This solution is faster, cheaper and ensures that the ceiling will handle 1 water tank. The only thing is that the pillars will have to stand in the kitchen and eventually also in other rooms below the ceiling, which might decrease the living comfort a bit. In case more water tanks will be required in the future, every time we will have to invest in preparation and fixation of more pillars. Those additional pillars will eventually make it impossible to open the oven doors, stand by the sink to do the dishes and overall will make the living for the residents of the house less convenient.

• The Ceiling = The Feature X; Option A = Refactoring; Option B = Increased expenses on maintenance and future development w/o refactoring; Residents of the house = users of the system/end customers

The car

Imagine you buy a car which is reliable and fun to drive. Five years later, the government will tell you that the very same car (which is still reliable and fun to drive!) needs to upgrade its catalytic converter in order to comply with the latest environmental laws. If you will not upgrade it will still be fine, no worries, but you will have to pay more 💲 on the environmental taxes from now.

• The car = The Feature X; Upgrade = Refactoring; Latest environmental laws = Current project/product with lots of new functionalities developed on top of Feature X; Increased environmental taxes = Technical debt, increased costs of maintenance and future development

The garden

You have a garden. You nourish and water every flower, shrub, and tree. From time to time you plant a new one. You do everything right. Now as time goes, you can see some of the plants are struggling 🍂. Some started to be weak and lose blossoms very early, some of your new plants barely grow.

You check the garden as a whole and find out that some trees grew quite high and now throw shadows on the new flowers which don’t have enough sunlight. The same with shrubs — you have noticed that some shrubs are growing quite wild and start to interfere with others.

What you will decide to do is to replant the flowers which are currently in the trees’ shadow so they can blossom fully. Also, you will trim the shrubs, so they do not interfere with others anymore.

Your garden as a whole is healthy. You can enjoy the scent of lilac, admire the simple and pure beauty of tulips and pay respect to a fully grown majestic walnut tree.

• The garden = your project/product; Replanting/trimming = refactoring

Bottom line

The typical situation as described at the beginning of this article should never occur in the first place. But when it does, learning through examples could significantly help you when guiding the project team and stakeholders.

On your project, all relevant stakeholders should be continuously educated and know what refactoring means. Everyone should know the meaning of technical debt.

First thoughts on refactoring should already be employed in discussion over the Definition of Done. All stakeholders must be aware of how our software is made and what is the chosen approach for our project — shall there be a compromise between the best overall solution & fast solution? And how big should it be? How shall technical debt be prevented/mitigated and what are the associated risks?

It is essential that all team members can speak openly about technical debt without any embarrassment or shame as it is only through such transparency the project will be engaging for the team and will enable key stakeholders to make fact-based informed decisions.

We are ACTUM Digital and this piece was written by Martin Dušek, Director of Apollo Division. Feel free to get in touch.