Refactoring

Share this post
How we use tennis rankings for fixing bugs 🏸
refactoring.fm

How we use tennis rankings for fixing bugs 🏸

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

Luca Rossi
Oct 7, 2020
12
Share this post
How we use tennis rankings for fixing bugs 🏸
refactoring.fm

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 πŸ‘‡

Become a better tech leader ✨


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.

This post is for paid subscribers

Already a paid subscriber? Sign in
Β© 2023 Luca Rossi
Privacy βˆ™ Terms βˆ™ Collection notice
Start WritingGet the app
SubstackΒ is the home for great writing