How we use tennis rankings for fixing bugs 🏸

And why it turned out to be great. With a caveat.

Hey 👋 this is Luca! Welcome to a 🔒 weekly edition 🔒 of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

---

Last week I discussed our approach to maintenance, based on allocating a fixed weekly time with a dedicated cycle of planning and review.

I promised I would elaborate more on that, focusing on how we measured the process and improved it over time. So here we are!

In the first post I said we settled with 20-30% of the weekly dev time dedicated to maintenance. After I wrote it, a few people asked: "Isn't that too high?". While others said: "Isn't that too low?".

This seems one of those situations where the answer is inevitably "it depends", but no, I will take the leap and argue that this number should work just fine for almost everybody.

Let me explain.