My previous post was about how to get slots of time in your daily (or weekly) work to do some refactoring. I left my readers with the promise of techniques to fit the refactoring work into these small slots.
Obviously, it won’t be possible to perform any refactoring of any size in this way. With a bit of discipline and know-how though, it is possible to deal with quite a lot by splitting them up.
Baby steps are small increments of working software. The idea is that we test, commit, integrate and even deploy every small code change ! Using baby steps, we can perform large scale refactorings little by little. Refactoring in this way might seem involved, but it’s so much safer that it’s a no brainer once you’ve tried it ! Refactoring in baby steps can be challenging to master though.
10 years ago, I used to work in a large bank in Paris. I had been dabbling on my own with eXtreme Programming for a few years, when we started a small project. I was to become the informal XP coach. The project was about connecting to an online brokering service. It involved adapting an existing domain library. It went out pretty well. More precisely, we created very few bugs in production, which was very different from the norm at the time. I remember this feedback from the manager :
We managed to move the code from X to Y through a succession of working baby steps ! That’s pretty uncommon ! A manager in 2006
Keep in mind that this was 10 years ago. We had not done anything special except trying to apply eXtreme Programming. Nowadays, as Continuous Integration has become mainstream these skills are becoming more common. That said, we still need to learn how to apply incremental software development to large scale refactoring. This is what I’m going to write about today.
This is the seventh 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.
Team TDD Coding Dojos
Learning to work in baby steps is not as complicated as it might first seem. The safest and easiest way is to setup a team TDD coding dojo. With its Red-Green-Refactor loop TDD sets up a baby steps rhythm. As I’ll explain in my next post, baby steps work best when all the team uses them. That’s another thing the team Coding Dojo helps with.
💡 TDD has a baby steps rhythm baked in.
We can push the learning further. For example, we can use the baby steps constraint during a few coding dojo sessions. With this constraint, we revert the code if tests fail for more than 2 minutes ! Here is a way to go at it :
- Setup continuous testing : NCrunch in .Net, Guard in Ruby or Infinitest in Java)
- Only use automated refactorings or extremely simple code changes in order to ….
- … keep the code compiling all the time …
- … and cut the time the tests fail as much as possible
One way to keep the tests green all the time is to use a slightly different TDD loop, as Nat Pryce suggests :
Here is how it goes.
- Add a new failing test
- If it’s trivial to fix, fix it. We are done
- If not, see what’s missing in the code
- Comment the test to get back to a green state
- Refactor the code to add what’s missing (and use other tests if needed)
- Uncomment the test
- Repeat from step 2
When doing this at the scale of a real life story or feature, we’d use
git stash instead of comments. This way of working has a name, it’s called the Mikado Method. It is at the heart of making baby steps work in real life.
💡 The Mikado Method is at the heart of making baby steps work in real life
Take a break
With TDD and the Mikado Method we can put the refactoring on pause. We can perform a small increment of the refactoring, commit and deploy it … and pause ! We’ll work on business features for a while, and resume the refactoring later on.
When done well, it feels slow. We have to remember that the alternative is to convince business people of prioritizing a refactoring … As we’ll regularly ship baby steps of a large scale refactoring, we’ll know we’re on the good track !
More to come
Unfortunately, even with bandwidth and skills, we are not there yet … It’s one thing for developers to do incremental software development of large scale refactoring on their own. It’s another to do it as a team !
This was the seventh post in a series about how to get sponsorship for large scale refactoring. Next post will be about how to manage constant merciless refactoring and baby steps as a team.