Let’s look at some of the boons, red flags and fine lines when restructuring the software already in production.
Firstly, how can one end up having an idea like that?
Say you are a product owner participating at one of your team’s stand-ups. In all probability, it might occur that one of the full-stack developers whom you’ve come to respect for her sanity drops something of the sort: “I’m planning to refactor the code we merged two weeks ago. The recent snap surveys have convinced the business side to add multiple payment methods instead of just Paypal. Code wise it means distinguishing between different layers of abstraction.”
Re… what? Yes! Perhaps we should get the terminology straight.
“Refactoring” can either be interpreted as a noun or a verb. The noun is defined as “a change made to the internal structure of the software to make it easier to understand and cheaper to modify without changing its observable behaviour.” The verb amounts to taking action to reach that aim.
Thus, the developer suggesting a “refactoring” is essentially proposing to redo the internal structure of your software by ending up with a different kind of structure, while referring to vague aims of “understanding it better” and making it “cheaper to modify”. Ravings of an ivory tower?
No, they’re not!
Refactoring is known for improving the design, helping to spot the bugs and facilitating the fast delivery of new features by rendering a cleaner structure. However, like many other things in this business, its scope, timing and methodology depend on the circumstances.
There are few firm rules when not to refactor. For instance, when it’s easier to rewrite the whole thing altogether or when dealing with the intrinsics of an external library, your team doesn’t even have to maintain. Though how to administer in the early stages of the product development or while running a startup that has just started up?
As counterintuitive as it might seem, the beginnings of software projects are much more receptive to all kinds of refactoring ideas. There isn’t much there yet, so it’s a lot easier to make fundamental changes to the structure. As a product owner, allow yourself to learn that while time to market is important, it isn’t all that’s there. Launching a messy code, which by the way always has a margin of subjectivity to it, but which can be narrowed to an uncomfortable reading and to the lack of a sense of ownership, should be translated into:
- slower bug repairs,
- difficulties with new features,
- locking yourself to a set of developers who have your product “in their heads”.
In other words – messy code means a fragile product. On the other hand, as a product owner of a startup, you have to deliver, launch and sell. Otherwise, you have nothing.
What to do?
Start by striking a fine line between refactoring and not refactoring as you spot the red flags. For instance, if the developer says:
- for the third week row that she is refactoring – that’s curious because the dominating philosophy in refactoring illustrates how it can be done incrementally, swiftly and efficiently;
- that the code is broken because she is refactoring – according to Martin Fowler: “If someone says their code was broken for a couple of days while they are refactoring, you can be pretty sure they were not refactoring”;
- that she cannot explain in detail which refactoring patterns she is using or argument as to why she has decided to use one pattern or another – this is fishy for several reasons. Still, for starters, there’s an abundance of resources for refactoring patterns with instructions of their relevant use cases;
- that there was no way of verifying the refactoring worked as intended because there were no tests – this is a serious flaw in terms of prerequisites: refactoring necessitates the existence of a solid suite of self-checking tests.
True, you don’t have to get all paranoid when someone drops the r-word. If you truly trust your team and you are sure that they know what they’re doing, let them carry on. It should be the team’s responsibility to agree on the need and the character of refactorings. Yet if you have to deliver on a tight schedule or your development team is entirely new to you, you might want to have your checks and balances in place. Watch out for the red flags, but avoid turning it into a dogfight. The best refactorings as well as the best avoidances of refactorings, for that matter, are based on good conversations.
The author would like to thank Andrei Zhuk, Meelik Gornoi and Mikk Soone for their pertinent comments and creative suggestions to the draft of this post.
