Summary
A rule such as “TDD is mandatory” or “80% coverage” changes the indicators, not the habit: the tests arrive after the code, the coverage target is met with tests that often assert nothing, and the team still designs first and checks later. The article argues for practice instead: the kata, a short exercise repeated until the moves come naturally, in a setting where nothing ships and mistakes cost nothing.
It describes how to make katas last as a team ritual. Subjects are prepared with the team’s technical leads and built from what hurts on the project. They follow a progression, level by level: clean code and the SOLID principles, then tests and TDD, then hexagonal and clean architecture, and only later domain-driven design, microservices, distributed patterns and CQRS. Pair programming on the real code follows each session; without it, the kata stays an exercise.
It also explains why the ritual collapses. “No time” is the first reason teams give, and it is true. Katas hold only with time set aside: half days blocked in the calendar, dedicated time for the leads and the teams, and a lead role that rotates so the practice never goes dormant.
Key ideas
- A rule changes the indicators, not the habit; what changes how a team writes code is practice, repeated in a setting where nothing ships.
- Kata subjects are prepared with the team’s technical leads and built from the project’s real difficulties, one practice per subject.
- Katas progress level by level, because the order matters: clean code and SOLID, then tests and TDD, then hexagonal and clean architecture, then domain-driven design and distributed patterns.
- Katas collapse without time set aside and without a link to the real code: blocked half days, pair programming on the project and a rotating lead role keep them alive.