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?

Introducing refactoring

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)

Conclusion

Cautionary tale:

• 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)

link to pics