A Surprising Way How To Teach Evolutionary Design
Evolutionary Design might be the most valuable yet impenetrable XP practice. Use TCR to practice baby-steps coding, the cornerstone of Evolutionary Design.
Evolutionary Design is my very favorite XP practice, but also the one that took me the longest to accept. It’s also the hardest to teach.
More than just software development skills, it [Note: evolutionary design] also takes humility, patience, restraint, discipline, and confidence.
People don’t learn new habits overnight. Three days barely scratches the surface, so sitting with them as they work through real stuff, and showing how things play out, is critical. It can be months before better habits stick.
Performing Evolutionary Design makes the lives of developers better! With it, a team can re-orient its software design according to the latest challenges. This makes progress steadier, more predictable, and the pace more sustainable!
For Kent Beck, master programmers split large code changes into small steps. Baby steps are the building blocks of continuous software design evolution. Baby-steps programming is the fundamental skill for evolutionary design.
Unfortunately, teaching baby steps is not easy. Participants tend to stick to wide steps. Even in a TDD coaching session and even as we remind them!
Wouldn’t you love to run baby-steps training sessions and teach evolutionary design faster?
It turns out that using TCR (test && commit || revert) in practice sessions does that!
How we started to run TCR practice sessions
Thomas Deniffel’s post about TCR Variants made a massive impression on me. I tried TCR with 1 or 2 katas and then suggested to my coach colleagues to experiment too. Everyone liked how it ‘forced’ us to stick to baby steps.
Here is what our TCR flow looks like:
- It watches the file system for changes to the code
- As soon as it detects some changes, it builds and runs the tests
- If the tests fail, it reverts
- If the tests pass, it commits
- It repeats
If we are too bold or ambitious (or pretentious) with a code change, the tests fail, and the change gets reverted. One quickly learns that the easiest way to go through an exercise with TCR is to stick to baby steps.
Having participants stick to baby steps during a code kata has always been an issue. So we agreed to experiment with TCR in a few training sessions.
This was a success! The feedback after our test sessions was excellent! As a result, TCR has become the default for every session we run.
What do participants say?
As I said, up to now, feedback has been great. Here are some examples of what people said at the end of a session.
It’s fun!
It’s almost a ‘gamified’ way to go through code katas!
There’s a poker flavor of ‘betting’ on your change.
It stretches coding muscles.
It’s TDD on steroids!
I learned how to do more rigorous katas.
I pushed baby steps to 11!
At first, I was skeptical about the Revert thing. But once I realized it’s meant as a practice tool; I started to appreciate its ruthlessness 😀
It yields more profound lessons.
We were lost in endless refactoring, and the tool taught us a lesson: to let go!
It’s good for the focus because you must stick to what you are doing now. And it’s good for the ego because it’s a script, not a human, that tells you to use smaller steps!
It creates a real feeling of progression!
I learned to focus more on each step rather than wanting to solve the problem.
TCR is like a workout machine!
TCR is a bit like a workout machine for TDD practice sessions. It makes the sessions more challenging and interesting. As a result, it’s a learning accelerator.
What exactly changes with TCR?
A classic TDD practice session
TDD-rookies tend not to run the tests often enough and spend too much time out of green-state. Here is the situation I have often observed:
- Participants write a test.
- They write way more code than needed to pass the test.
- They manage to pass the test with a lot of thinking.
- Unfortunately, they broke other tests in the process.
- Eventually, they take 15 minutes or more to debug everything back to green.
As coaches, we have to point out every time they start on such a difficult path, but:
- It’s exhausting to be the killjoy all the time.
- We cannot keep an eye on everyone at the same time. As a result, many participants struggle with long steps.
TCR as a coach bot!
Things are different in a TCR practice session:
- Are participants making an ambitious giant step that fails? => The code is reverted.
- Did they break other tests while passing the new one? => The code is reverted.
TCR keeps the code in a green state. It “forces” participants to stick to baby steps. It does that without us having to remind people all the time. It does that without us having to be there!
As a bonus, we can have more people in a single session!
From TCR to evolutionary design
J.B. Rainsberger explains that practicing micro-steps teaches how to ‘chunk’ them into larger ones. With TCR, participants experience going through a programming task with baby steps. They can even check the git-log to see the detailed steps they used. This is how they learn evolutionary design.
See for yourself!
The simplest way to give TCR a try is to run "test" && "commit" || "revert" instead of just test.
If you are using git, you can commit with git commit -am "TCR" and revert with git restore .. The test command depends on the language and toolchain you are using. Pick your favorite kata and give it a go! If you lack inspiration, go with the classic Bowling Game. I have seen TDD veterans get reverted on this kata and learn from TCR. There’s definitely something for everyone here. I’m sure you will have fun too!
Batteries included!
At work, we have been working on a more advanced TCR tool. You can find it at https://github.com/murex/TCR. You can also find a sample kata repo at https://github.com/murex/Kata-BowlingGame.
Compared to terminal commands, it also:
- watches the file system, and runs TCR as soon it spots some file changes
- pushes and pulls through an online repo to enable remote mobbing with git-handover
- provides a mob timer to switch the driver role during the session
- can commit reverts for participants to retrospect on what got reverted
- finally, it’s also gentler than strict TCR because it does not revert the tests
The tool currently supports git, Java, C#, C++, and Go, but it’s open to contributions!
Give TCR a try and share your experience! I’d also love to read about your tips for teaching evolutionary design.
Here are other posts that you might find interesting:
- How to deliver a remote training with code-katas and randori in pairs
- Incremental Software Development Strategies for Large Scale Refactoring #2: Baby Steps
- A coding dojo exercises plan toward refactoring legacy code
- Why you should start a team coding dojo Randori right now
- How to start a team coding dojo Randori today
Leave a comment