Katas - why, when and how
Katas are the way that developers use for sharping their skills in a particular subject. For example, TDD, design patters, SOLID principles or any kind of design to develop software - out there, there are katas for software architecture.
In some way, this is a more elaborated post from my linkedin post:
Katas, have their name and inspiration from the Japanese karate, that focus on a specific and only one thing at time and bet on repetition to improve little by little. As already mentioned by Felienne in her book The programmer’s brain  repetition is not something that programmers rely on to improve their skills, in that sense, repetition seems to be something bad that should be avoided at all costs.
The first time I got in touch with katas was a few years ago, back in Brazil I had the opportunity to meet developers that used that to learn new techniques for programming.
Today,I still use such approach to learn new things, I created a repository that holds the katas I did and to keep track of my evolution through time. The kata I enjoyed the most so far is The Mars Rover. The Mars Rover aims (as the kata goes) to tackle the state management problem while developing an application. The idea is simple: we will send a rover to mars and to communicate with it we will send commands as a string format and each letter corresponds to what the rover will do: go north, go south, go east or go west. The catch is on how to approach such movements, a bunch of if will do the trick, but as the state start to get complicated better refactors come to play, for example, using the state or command pattern.
I had the opportunity to see other developers tackling the mars rover kata in many different ways, functional style, oop style, following command pattern, following state pattern, without any pattern and others that I can’t remember.
One thing though, that keeps me thinking, even with such variety of styles on tackling mars rover, is the argument developers often use to compare the miss match between the katas and the “real business applications”.
Real business applications
Often, the argument of “real business applications” come into play when katas are in the discussion. Usually, this is used as an argument against katas, if they do not represent real world applications, why would you bother to try them? Personally I try to counter argument such approach with the learning process.
Have you ever thought about how you learn something?
- Focused mode
- Diffused mode and
- Deliberate practice
While I elaborate more on the first two items, I will take some steps further here and elaborate why I think this is crucial for katas and the learning objective that it has.
Focused and diffused mode are the first two steps while trying to understand something - take the classroom example, focused mode would be the teacher saying something and you listening carefully. Or for example, you reading a book and taking notes. Diffused mode is the next step where the things that took place in the focused mode, start to sit inside your head.
Diffused mode is as important as the focused mode, as you need to digest the new information. Once digested, you can start to link that with previous knowledge you already had. Last, but not least, is deliberated practice. In other words, to put in practice what you understand and improve on that through practice.
On one hand, through katas, you are mixing all of three learning strategies with an emphasis on deliberate practice, in the end, there will be code. All in all, before you can apply such techniques on the daily-basis, you need first, to learn them. At work, where the “real business application” argument comes from, once you have this knowledge, you simply apply them.
On the other hand, the miss match in the argument “real business application”, is also, somehow connected to the lack of understanding on how to learn and improve a specific skill.
Last but not least, it’s possible to list some specific katas that are related to “real business application”.
- Bank kata - Often practiced to sharp the outside-in style of TDD, mocks (Test Doubles) are essential part of the testing first approach
- Gilded rose kata - Developers are most likely to join projects that have already some code in place, due to the nature of programming, it’s known by research that developers read more code than write. This kata, focuses on understanding the not well maintained code and gives the scenario to explore possible refactors and improvements.
- Racing car kata - Focuses on SOLID principles.
Emily Bache (she is one of the authors I referred in the kata list) also wrote a infoq article that describes how she uses katas to spread technical practices in organizations.
Besides my support for using katas as a way of learning and also improving skills, she depicts a point that deserves attention when it comes to “enterprise” setup:
Few organizations are successful in adopting TDD. Developers usually need support to move beyond TDD practice exercises to a full-scale production codebase.
How to Spread Technical Practices Like TDD in an Organization - Emily Bache
Which is a double edge sword, after incorporating the technical practices, developers still need support for transitioning on a “real business application”.
Another reading that goes along the same direction is the blog post by Philippe Bourgau, he goes into more details on the history behind katas.
- F. Hermans, The programmer’s brain. Manning, 2021.
- B. Oakley and D. T. Sejnowski, “Learning How to Learn: Powerful mental tools to help you master tough subjects,” 2021 [Online]. Available at: https://www.coursera.org/learn/learning-how-to-learn. [Accessed: 25-Jul-2021]