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.