My devs are always refactoring! why? [part-2]

On Wed, 01 Jun 2022, by @lucasdicioccio, 473 words, 1 links, 0images.

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?

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