2 days of training, 6 months of doubts
Training is, at best, a spark. Without ongoing support, putting what you’ve learned into practice is often difficult.
You’ve decided to learn Test-Driven Development (TDD): great move!
So off you go for two days, at the end of which you’ll know how to write tests that embody all the F.I.R.S.T. qualities and will have mastered the three fundamental rules of TDD as well as their implementation (red/green/refactor). Convinced of the benefits of this method in terms of code quality, coverage, and documentation, you’ll see your practice completely transformed as soon as you return to the office the following Monday, after a restful weekend. Congratulations.
These two days of training have also allowed you to explore several variants of TDD (Inside-Out, Outside-In, test && commit || revert), which you now use effectively depending on the situation. Because you’re incredibly intuitive, you’ll have quickly realized that it’s best not to rely too heavily on tests and to simply view them for what they are: a tool to help you write code. Well done.
This new practice will fit seamlessly into your existing toolkit, alongside other types of tests and advanced use of typing, a powerful alternative when it comes to expressing business constraints. Thus, by the end of these two days, you’ll be applying TDD in a way that’s both new and well-reasoned, just as outlined in the training objectives. Well done.
Well done, you’re really good… but the reality is a little more complicated.
It’s all a matter of time and practice: “Knowledge is gained through experience; everything else is just information,” as a physicist who has become part of popular culture liked to say. Especially since you’d first have to retain the information. Two full days of TDD training are too much for many people to take in. You retain very little from such a session: 20%, they say (though the statistic isn’t sufficiently substantiated).
Furthermore, the leap from theory to practice can be a big one. The examples provided in training are generally well-defined, the problems are clearly stated, and the complexity is limited. But when you’re back working on the codebase, you have to deal with technical debt, the inevitable emergencies, and, more generally, “real” life. Everything is more complicated. This is precisely where you need a methodical approach, but also guidance. Change takes time and raises many doubts. Alone at the keyboard, you can find the questions overwhelming at times.
Supporting a team over the long term, by contrast, is all about flexibility and adaptability. Here’s an example of how that works:
- 1-day introductory training in groups of 2 or 3: theoretical foundations and hands-on practice with a few simple exercises (katas);
- Ongoing one-on-one coaching, 1.5 hours every two weeks, for several months. Katas of increasing difficulty and real-world scenarios provided by the developer;
- After some time has passed, a half-day of group training to put what you’ve learned into perspective, introduce some nuance (when to use TDD?), and cover a bit more theory (Inside-Out/Outside-In approaches), if the timing is right.
Above all, this format lets us pinpoint exactly which areas need work: perhaps TDD isn’t the top priority for every developer? In fact, it’s better to avoid defining a coaching program based on a set of practices, no matter how good they may be, and instead start with the challenges observed on a daily basis, both individually and as a team (high lead time, bugs, regressions, etc.).
For coaching to work, strong managerial support is essential, and this commitment must be reflected in practice through dedicated time (even if it competes with day-to-day operations during the investment phase). I recommend working on a small scale (two or three teams at most) and strictly on a voluntary basis, with people who are actively seeking answers. Subsequently, we often see a “ripple effect,” whereby knowledge spreads from person to person through informal practices (pair programming) or more organized ones (communities of practice, Brown Bag Lunches, etc.)
In any case, this transformation takes time. You shouldn’t expect to see real benefits for at least 6 months, or even a year. The cost is, of course, far higher than that of a training course, but so are the benefits. While one-off training sessions are sometimes just a formality to check a box, this kind of support, on the other hand, is an investment.
While training is an excellent starting point, it is, at best, a spark. Training clearly cannot be enough—and, in fact, it’s probably not even necessary.