Who has felt the frustration of wanting to improve and refactor a feature or piece of code because they can’t dedicate time to it?
Do technical user stories or tech improvement user stories fall lower in the prioritization than we would like as developers?
Have you ever started a refactor and had to stop because you were spending too much time on the user story?
Have you ever been identified with any of the above questions?
Most of us who are dedicated to product development feel that way sometimes, carrying this feeling inside of us, or not so inside,… and now is when we ask ourselves, what can we do with this feeling?
At the beginning of last year my answer would have been very different and I will explain why below.
In a training we did with our great Pedro Pardal, technical coach at Voxel (pedro’s talk about Legacy at #SDSummit), some of these same questions came up and when we posed them to Pedro he shared with us some ideas on how this situation could be addressed.
One of them was a very simple but effective method, this method is known as 10 min refactor.
10 min refactor
This method consists of reserving a 10 minute time slot every day to refactor a piece of code in a safe way.
It doesn’t need to be something big, it is to look for something and improve it, whether it is a rename to make something better understood or the extraction of a method. We will always find something to improve in a safe way.
The power of this method lies in dedicating those 10 minutes every day to improve.
If we add those 10 minutes from all the people in the team, every working day of the week… you don’t just see 10 minutes, you see much more. In this way, we will improve our systems incrementally, improving them little by little and almost without realizing it.
Drop by drop, the glass will fill up.
And what about those refactors that we consider big? Well, they are dealt with in the same way: the first day we extract methods, the second day we extract in a class, the third day we create the tests of that class and so on.
Refactors in a safe way.
I would like to highlight the phrase mentioned in the previous point “refactor a piece of code in a safe way”.
Generally we do it using an automatic refactoring tool, such as Resharper, although any other similar tool will do. These kinds of tools assure us that the code will behave in the same way if we change it automatically, avoiding human errors.
It is also important to have a good coverage of tests that allow us to make changes safely. And if you don’t have them, with a 10 min refactor you can create them for later refactoring.
What can I refactor in 10 minutes?
The answer is simple, anything.
In the Travel team, at Voxel, we usually apply the Scout rule: leave it as clean as you would like to find it.
If we see that there is an important dedication to leave it that way, we write it down to tackle it later in these 10 minutes of refactoring.
This includes not only code, but we also include tests, documentation, team processes etc. Everything can be improved and little by little it is achieved.
Final conclusion
I encourage you to try these 10 minutes a day that changed the way we work and improve our team. Draw your own conclusions about what it brings and tell us about it.
About the author
