Key Takeaways
- Continuous delivery stalls when we cannot reduce the batch size further.
- The practice of TCR (test && commit || revert) teaches how to write code in smaller chunks, reducing batch size further.
- TCR yields high coverage by design, which smooths down the downstream testing pipeline.
- TCR supports remote mob/ensemble programming by design through the git-handover mechanism.
- In essence, TCR is a simple script you can set up now. There are also open-source implementations available with more features and options.
A while ago, a colleague and I ran a code kata at a conference in Paris. Here were the kinds of learnings that the people expressed at the end:
I thought I was doing small steps, but I discovered I could make them even smaller!
I still need more experience with the TDD itself!
I got lost in endless refactoring.
By now, DevOps and Continuous Delivery are widespread in the industry. But, is work done in small slices, continuously integrated, and played with? Many teams still work with feature branches, integrating only full features!
Wouldn’t it be great if writing code in baby steps had become second nature to developers? Achieving the full potential of Trunk-Based development, DevOps, and Continuous Delivery!
TCR is a technique that forces you to write code in baby steps! It’s also a harsh but effective teacher. Let’s learn more about it. We’ll see how developers are using it to do more continuous delivery and to coach their teammates:
- TCR: “TDD on steroids!”
- Interview of Guillaume, who uses TCR as a coaching tool
- Interview of Xavier, who uses TCR for all production work
- Testing, mobbing, and other benefits of TCR
- How to give TCR a try!
TCR: “TDD on Steroids!”
TCR stands for Test and Commit or Revert. It replaces the test command with a test && commit || revert command
. So, developers will run the TCR command instead of launching test to check their code is working. If the code works as expected, TCR commits it to the version control system. If the code does not work, TCR reverts it to its latest working state!
TCR started as a crazy experiment by Lars Barlindhaug, Oddmund Strømme, Ole Johannessen, and Kent Beck during a Code Camp in Oslo. Kent Beck then spread the word through his blog. Kent Beck claims we should try stupid ideas because sometimes, they turn out to be brilliant! Whether TCR is stupid or brilliant is still an open question. Yet people who stick with it long enough find it illuminating!
You’re bound to learn something. (Kent Beck about trying TCR)
Indeed, developers who gave TCR a serious try report many benefits:
- It challenges you to write smaller coding steps.
- It makes practice sessions more fun.
- It makes work more sustainable and less tiring!
- It improves the continuous testing workflow between devs and other team members.
Let’s read what they say firsthand. Here are interviews with two TCR practitioners.
Interview with Guillaume Faas, Who Uses TCR as a Coaching Tool
Hi Guillaume, can you tell us about yourself in a few words?
Guillaume Faas: Sure. My name’s Guillaume, and I’m currently a .NET Developer Advocate at Vonage. I’ve been in the Software industry for almost 15 years, in the .NET ecosystem all the way through. However, if I had to pick one milestone from my career, it wouldn’t be a role or a project but the acknowledgment of Software Craftsmanship. Indeed, it drastically changed my view on software development, and there’s a before and an after. Since then, I consistently try to spread the mindset and its values.
Can you share your TCR story: how you got into TCR? What were your first impressions?
Faas: Funny thing that you ask. My first encounter with TCR was during one of your workshops, specifically, the Bowling game in the Software Craftsmanship Luxembourg meetup. I remember the workshop being so much fun and enlightening. But unfortunately, our baby steps were not so small, and we started to fear saving our changes. Nevertheless, I came out of it excited with the will to practice more.
Today, what do you use TCR for?
Faas: To be fully transparent, I apply TCR through the tool the Murex tech coaching team built. I mainly use it for katas during coaching sessions. It’s a great way to teach TDD because it brings more ideas and is not necessarily harder. I also used it on production code, but I’d advise people to be careful. Verifying that every test passes every single time can drastically slow down your feedback loop. Finally, I also used it during technical tests as a candidate.
What benefits have you noticed from using TCR in the training context?
Faas: People realize they do not trust the code they write. As I said before, we feared saving our changes. There’s a clear connection with the following quote from Kent Beck: “Test-driven development is a way of managing fear during programming.” Also, we all think we’re working in small increments. Spoiler: we’re all wrong. TCR forces you to go small and often, bringing many benefits, including a sustainable pace and less tiring work.
How do people typically react when confronted with TCR during training?
Faas: “Oh no, I’m going to lose my code.” And it might be right. But people quickly realize they will only lose a little if they reduce their TDD cycles. It also becomes quite addictive and fun. You’re encouraged to challenge your confidence in the code you just wrote. I’ve observed the following every single time: people started to bet on the test output before running the tests.
What challenges did you face, or are you still facing, when using TCR for training?
Faas: People are usually intimidated. They believe they need to learn another thing simultaneously, which is wrong. Also, reverting code feels like a waste of productivity. So the challenge is to make them try anyway.
Have you any recommendations for readers who want to use TCR to practice or train others?
Faas: Kent Beck’s blog post on the topic itself is an excellent way to start. Also, being a consistent reader, I can only recommend your blog. It contains fantastic articles like, for example, the one on evolutionary design. Otherwise, practice makes perfect. So join some people for kata and experiment. It’s fun, and you’re guaranteed to learn something.
Where do you see TCR in the future of software engineering?
Faas: That’s a tough one. I advocate TDD and TCR as much as I can. Although TCR is pretty recent (2018, if I recall), TDD goes back to the early 90s and still needs to be widely adopted. Most of the developers I encounter still never wrote a test or, worse, are allergic to tests! We may have several years of hustle before TCR becomes a thing. As practitioners, we must spread the word and accelerate its adoption.
According to you, what should we do to bring TCR one step closer to that vision?
Faas: I have to go back to the previous question. We all know TDD is a beautiful practice, and most thought leaders agree. But where did it fail? How is it not more adopted, given the number of talks, books, and articles praising its benefits? How do we guarantee a different outcome? I don’t have a magical solution. We must bring awareness on the matter, one mob at a time.
Interview with Xavier Detant, Who Uses TCR for All Production Work
Hi Xavier, can you tell us about yourself in a few words?
Xavier Detant: I am currently CTO at Great Place To Work France and will soon be joining Eove. I worked for ten years as a contractor before becoming employed full-time at a software company. I discovered TDD and adopted it 8 or 9 years ago. I am the father of a very cute boy and the husband of a lovely wife.
Can you share your TCR story: how you got into TCR? What were your first impressions?
Detant: I discovered TCR, like many, through Kent Beck’s blog post. My first thought was, “that sound like an interesting constraint for a kata,” so I tried it. At first, it reminded me of the “your computer has a defect” constraint where a script on the background resets your code through git every two minutes, and you can only commit when it’s green. The main difference being the script is your test, and the loop is as long or as short as you want. My first reaction was, “I love it for refactoring but not seeing any test going to red is very uncomfortable.” I was curious if the discomfort would stick, so I did more katas. Doing so, I really enjoyed that:
- My code was shared as soon as it was green. It showed great promises for continuous integration.
- The reverts gave me feedback on my fatigue. I could make bigger steps at the beginning of a session than at the end. When I couldn’t make a step anymore, I stopped and would easily find a solution the next day!
- It fits perfectly with the refactoring definition and the mikado method.
I really disliked the following:
- I could not see my tests go red. I lost confidence in my tests and wasn’t able to improve their error messages.
- I had a LOT of commit messages to write, 99% of which were useless and paraphrasing the diff.
Because of that, I adapted the flow of TCR to be closer to TDD but stuck to the stuff I liked from TCR. The symmetric of TCR is TRC: run the tests; if green, revert; otherwise, commit. That’s a very good fit for the red phase of TDD. So I created a script to do that (and simplify some complexities like avoiding red commits when you push). I liked the result and have been using it since.
What do you use TCR for?
Detant: I use it for everything I code. It completes my TDD workflow.
What benefits have you noticed from using TCR in your day-to-day work?
Detant: An individual benefit is feedback on your fatigue state. If you are too tired to make a good move, you get literally stuck. And you see the size of your steps shrinking during the day. So you are conscious of it at any time while still going as fast as you actually can.
What are the impacts of using TCR on the software construction process?
Detant: An organizational benefit is improved continuous integration and delivery. At any time, anyone with access to the pre-production platform can see what I have done on my task and give feedback. It made a big step forward in agility as we can draft something, start using it at the same time, and improve according to the first impression. That also means no hard feelings:
- “Of course, I can change 90% of the feature since I didn’t code most of it yet!”
- “Want to test the integration with another system? Let me fake it so we can see the workflow and eventually fix it.”
- “Nothing to fix? Awesome, I’ll continue as planned then.”
That’s super comfortable, relaxed, and constructive.
What challenges did you face, or are you still facing, when using TCR in production work?
Detant: The main challenge is not to “cheat.” In your IDE, you are just a CTRL+Z away from getting back the code you just lost (Note: just after TCR reverted). If you lost it, there’s a reason. Stop and think about it! Of course, pragmatism is key. If you saw a typo at the same time as you ran your tests, allow yourself to cheat. Yes, I still face it, especially at the end of the day, when I don’t want to admit that I am too tired to do quality work and want to finish what I am doing. Every time I cheated for that reason, I regretted it the next day.
Have you got any recommendations for readers who want to start using TCR?
Detant: Try TCR for the refactoring phase only at first. Then, discover with katas and start using it on production code. Finally, if you like it, find a way to expand it outside of the refactoring steps.
Where do you see TCR in the future of software engineering?
Detant: I don’t think TCR will go as far as TDD did (and TDD is still not ubiquitous). I think it will be a very good starting point for new ideas of working, though. Sadly, as for TDD, we’ll probably need to wait 20 years to see different ways of working becoming “mainstream.”
According to you, what should we do to bring TCR one step closer to that vision?
Detant: Try ideas. We won’t improve our way of working if we don’t try things—even the “obviously stupid” ones. We have the luxury of being able to create side projects for fun. We are allowed to fail at our side projects for silly reasons. Let’s leverage that. Heck, most projects can afford to fail for silly reasons since so many projects still fail for “non-silly” reasons like:
- Lack of user feedback
- Lack of product management
- Lack of tests
- etc
If a product is not life-critical, using new, untested ways of working is an option. Take risks! Our field is new, and we have much to discover, test, and learn. Be an explorer and share your adventures with us!
Testing, Mobbing, and Other Benefits of TCR
My colleagues and I have been practicing TCR too, and we observed more benefits!
High Coverage
TDD, followed by the book, results in high coverage by design. By enforcing a strict TDD, TCR yields even higher coverage! TCR leads to 90% or more solid branch coverage. The remaining uncovered code is constants or glue code.
Increased coverage is another way TCR improves continuous integration and delivery flow. By catching errors up-front, developer tests avoid failures in the downstream pipeline.
Remote Mob or Pair Programming Out of the Box
Git handover is a straightforward, robust, effective, and cheap way of doing remote pairing. It works by:
- sharing the code through git
- sharing your screen when you are the driver
By continuously committing small code changes, TCR makes git-handover seamless. It’s easy to tweak your TCR script to push when it commits. We can automate pulling the latest changes too. Role-switching in the mob becomes as simple as starting screen sharing!
Trainees Like It!
TDD is difficult to teach because applying it in ‘hairy’ production code is tricky for newbies. Surprisingly, it’s easier for people to buy in TCR! TCR seems crazy, and people don’t even think of using it in their day-to-day work. As trainers, we explain that it’s a tool to help them practice baby-steps programming. They get in a constructive ‘training’ mindset. Later, back at their desks, they can split their work into smaller steps, even in legacy and untested codebases!
How to Give TCR a Try?
Guillaume and Xavier said that the best way to get started with TCR is to try it on a kata! Just run git init and use a different command for your tests:
<your test command> && git commit -am "TCR" || git restore.
If you want a bit more bells and whistles, there are plenty of open-source tools for TCR:
- Thomas Deniffel wrote a post with many shell script variations around the TCR flow. For example, automatically running TCR on file changes.
- Xavier’s TCRDD tool lets you bet on and see failed tests.
- Lars Eckart wrote a JUnit 5 extension for TCR. It features code annotations to orchestrate when to run the different tests. It speeds up the feedback loop.
- The Murex tech coaching team TCR tool. It’s cross-language and has remote mobbing built-in.
Get used to TCR on a few katas! Then, once you get the knack for it, if you have fast enough tests on your production code, give it a try on pure refactoring!