This article is still considered unfinished and content may change significantly.
This article is the second in a series of articles on refactoring.
From a non-developer viewpoint, it may be hard to connect with developers who are always refactoring. I wrote this article to fill some gap I observed a number of times with non-technical stakeholders worried that tech teams where “always refactorin’”. Cannot developers refactor once and move to something more useful?
Let’s recollect what we have: we agglomerate code and see what sticks. When new features arrive, we either pause what we are doing and agglomerate more stuff. When new horizontal requirements pop-up and sets back all your shipped features, your project suffers.
A definition of refactoring
Refactoring is a technical task which consists in. While changing almost no behaviour.
Goal of the refactoring is pairwise:
- sediment and cement some idioms
- maintain an acceptable level of surprise/horror for people who need to touch the code or operate the system
Purely-technical tasks like changing the logging format are not really recognized as refactoring but they share most of the characteristics: from a business-user standpoint you see no behaviour, however from an operator-user standpoint the behaviour changes.
This absence of external changes is desirable and developers will bring up refactoring to help you understand how to classify this task: it takes work but you need not know how the sausage is made.
=> ⚠️ Could lead to some breach of trust. The catch: developer happiness and morale is part of their productivity.
I believe my team is always refactoring what should I do?
First, is it really true?
You need to settle on some acceptable amount of technical work, which includes refactors.
Pushing back in a healthy way
What is key to keep in mind: developers bring up refactoring tasks for a reason.
- upfront as preventative: when discussing new tasks, be honest about the amount of uncertainty you have with a feature, especially on things that are pretty structural like “can there be zero, one, many” items connected to a user, to a group etc.
- reframe/clarify whether it’s a refactoring or some other technical tasks, mostly you’ll be able to re-classify and you’ll realize that there is more complexity or richness to the work they do
- organizational: quantify the friction accumulated, did the lack of refactor led to extra friction? can you weigh the refactoring work? can you budget an amount of refactoring time?
- bluff: it’s a good way to lose trust so you have to be really sure some near wins will offset this; say that you need a bit more real-world feedback (it’s in general true, but it’s often a small-lie we tell themselves because of how hard it is to collect scientifically sound feedback)
- some strict business requirements may act as technical requirements, just that the business is more ok with post-poning than things like an emergency patch
- when the technical requirement is a program, you have the same questions to answer but at a much larger scale, you need to devise specific strategies to weigh ROI (recommended to have functional-architects)