My previous post advocated incremental software development for large scale refactorings. It’s less risky and it prevents tunnel effects. Most of all, it’s a lot easier to convince business people of engaging in a refactoring this way.
It’s one thing to understand why it’s the way to go, but it’s another to be able to do it ! In this post, I’ll start by explaining how to find the time to do constant merciless refactoring.
This is the sixth post in a series about how to get sponsorship for large scale refactoring. If you haven’t, I encourage you to start from the beginning.
Steal Take the time for constant merciless refactoring
If it hurts, do it more often ! Wisdom of the internet
As a child, I used to be a very untidy kid. Every few week, my room would get in a real mess, and my mum would order me to clean all this mess. I would then lose 1 or 2 hours tidying my room up. She used to tell me that if I kept things tidy as I used them, I would not have to lose this time. From the top of my 10 years old, I would judge this advice as nonsense.
Fast forward a few years, I am myself a parent and I’ve been working with legacy code for many years. These years have taught me how much I was wrong …
💡 The easiest refactorings to negotiate are the ones we don’t have to talk about !
The more refactoring we embed in ‘Business As Usual’, the more we’ll do, and the less we’ll argue with the business. We can wonder if this is still ‘professional’ ? In The Art Of Agile Development, James Shore explains that managing technical debt is the key to long term productivity. (Details in the Risk Management section of his book). As developers, we are the only experts in the code, the responsibility to keep it clean falls on us.
Never ask the permission to do a good job ! Doc Norton
There’s more to constant merciless refactoring ! It also keeps us in a good position to accept new features or refactorings later down the road.
Following are the 3 practices that make up constant merciless refactoring.
Yesterday’s weather and slack time
20 years ago, a promises of agile software development was to stick to a sustainable pace. When we are working with a flavor of Scrum, we can rely on it’s literature to inject some slack time. Slack time is buffer time at the end of every iteration. We should not plan any work during the slack, to accommodate with the unexpected. It’s a way to deliver on forecasts, whatever happens.
In short, if your velocity chart looks something like that :
Scrum tells us to plan what you delivered in your worst iteration for the next one ! When things will work bad, we’re still pretty likely to deliver what we wanted. When things work well, we’ll have time to tackle refactoring.
There’s a lot more to say about slack time. How to take some when you are using Kanban ? How to make sure you keep some when your velocity becomes pretty stable ? How to do you increase your velocity in the long term ? (I guess I’ll have to write a full blog post about this some day.)
The Boy Scout Rule
Always leave the file you are editing a little better than you found it. Bob Martin
Following this simple rule goes a long way to keep the code clean and ready for larger refactorings. It works arm in arm with Yesterday’s weather principle. The extra time we take for clean up impacts our capacity to plan stories and features. This creates time to keep on doing the boy scout rule in future iterations.
How ‘clean’ the code should be is a team decision. Coding conventions and a static code analyzer are very important to track the boy scout rule. I learned that code reviews, pairing, mobbing and coding dojos are great to agree on coding conventions.
Embedding refactoring in features
The Test Driven Development loop goes as Red-Green-Refactor.
The same loop goes on at larger scale for Acceptance or Feature Test. When repeated many times, the loop could as well be Refactor – Red – Green. In fact, it’s a lot easier to refactor when you know what feature you want to build than at the end of the previous one. (Nat Pryce wrote about that in more details)
💡 “Disguise” refactoring as first technical sub tasks of features to get them prioritized.
All this to say, we should start our features with the pre-requisite refactoring ! We should not build features on shaky foundations. We should also impact our estimates. In fact, it’s a lot easier to justify to business people at that moment. We don’t need to mention ‘refactoring’ or ‘clean up’. We can use technical sub-tasks to track these technical refactorings. Technical sub-tasks are the team’s and don’t need to be understandable by business people.
To be continued
Finding the time for constant merciless refactoring is one thing, but how do we fit the work in these short slots ? In the next post, I’ll continue about how to actually work in baby steps.
This was the sixth post about how to get sponsorship for large scale refactoring.