To begin, let’s take a look at the kata method itself. If the term katas reminds you of martial arts, you’re spot-on. “Kata” originates in Japanese and means “form”. In martial arts, it refers to patterns of movements that are practiced repeatedly in order to build muscle memory and perfect one’s skills. Coding katas work much in the same way: they are typically small exercises in which a developer is given a specific programming language with which they have to build a feature or solve a specific problem. These exercises help them to improve their skills through practice and repetition. Katas can help you learn all kinds of skills and examples can be found all over the web. A good starting point is Dave Thomas’ katas list or Gabe Montalvo’s awesome-katas repository.

These exercises are usually done in a training setting, rather than as part of a real-world project and can be done independently for self-guided learning or as a group activity. The latter of course has the added benefit of helping practitioners share knowledge and learn from one another.

Beyond helping you master your programming art, continuously using katas can help you learn much more about software development in general. Some of these things include:

• Basic design principles and patterns: developers can learn about the fundamental principles and patterns that are used in software design, and can practice applying these in a structured way
• Choosing appropriate technologies and frameworks: developers can learn how to select the technologies and frameworks that are most appropriate for a given project, also in consideration of factors such as performance, scalability, and maintainability
• Decompose a system into components and services: developers can learn how to divide a system into smaller, more manageable pieces, and can practice applying techniques such as modularity and separation of concerns
• How to consider trade-offs and make design decisions: developers can learn how to weigh the pros and cons of different design options, and can practice making informed decisions about the design of a system

Generally speaking, katas should be structured in such a way as to provide a clear and well-defined problem for the practitioner to solve. This means they include a specific problem statement with enough information to understand the context of the problem, clear objectives and limitations, a series of concrete tasks to work through, and criteria for the team to evaluate the solution it has devised.

Convinced? Okay, then let’s move on to our architecture workshop experiment.

From Coding to Architecture Katas

I suppose you can already see where this is going. We asked ourselves: what if we used the kata method not just to program, but to come up with useful system architectures? Our work at Turbine Kreuzberg has been moving more and more to the heart of companies’ digital landscapes. Often, we find ourselves building custom applications more or less from scratch. This makes it more important than ever to develop our skills in building system architectures from the ground up.

As with many things at Turbine, we wanted to make progress by trial and error. So, we kicked off a series of katas workshops, in which teams would practice designing a reasonable system architecture for a predefined use case. Of course, our objective was less about the resulting architecture and more about learning how to get there. Our top goals included improving the participants’ architecture design skills, giving developers previously unfamiliar with architecture design insights into a new domain, and offering a forum for knowledge exchange.

Our thinking: by preparing developers for design decisions in a safe environment, they would be better prepared for real life cases. In addition, by teaching teams how to structure systems they would also learn to distribute the development thus ownership of those systems over multiple teams.

We announced the upcoming two workshops regularly during our weekly internal “devtalks” sessions. Participation was on a voluntary basis. Each workshop began with a short intro to the kata method, as well as explaining the use case and tasks. Then, each team received an empty Miro board to work in, i.e. to structure their architecture and component overview. At the end, we gathered feedback about the method and the use case.

Our Use Case: “Fancy Food”

To provide our workshop teams with something useful to work on, we presented them with a fictitious but very realistic scenario: A (fake) start-up called Fancy Food has approached Turbine Kreuzberg with the proposal to build a minimum viable product (MVP), i.e. a first version of a product with just enough features to be usable by early customers. Fancy Food’s mission is to create tasty meals around people's dietary needs and lifestyle, in order to support their overall well-being. We were inspired by this architecture kata scenario we came across while preparing the workshop sessions.

To add some more detail, we came up with a series of prerequisites/requirements:

• Fancy Food has a kitchen which will prepare the meals
• Fancy Food uses smart fridges as their Points of Sale. Meals will be delivered to these Point of Sales from the kitchen.
• Customers will check availability of meals using Mobile/Web App in the nearby POS
• Customers go to the nearest available POS and purchase or pick-up the meals
• The system has to maintain the inventory levels at the POS

Our workshop teams’ tasks included identifying the Users/Clients, identifying use cases, deriving application components, designing the overall high-level architecture, and designing the architecture of the integration. As an added bonus, we tasked the participants with coming up with a sensible team structure for the use case and a high-level effort estimation for the implementation.

When comparing both workshop groups, we can see similarities in their proposed solutions. The first group focussed more in-depth, while the second one was broader and took more of an MVP-approach.

The first group identified the acting components and their relations by following the information flow of concrete data. This established a possible API specification for the different integration points, but it also took a very long time to map the whole system.

The second one also began discussing specific technologies suitable for implementing their solution, as well as their complexity tradeoffs and budget implications given the anticipated initial investment volume.

The second group additionally identified roles and their scope of actions within the business. From this they could deduce the components that are expert tools, which wouldn’t be needing that much attention up front for anything but core functionality.

The results have only confirmed the need to continuously do katas exercises, architecture-focused or otherwise. We have seen that practice makes perfect – or at least better. Our developers are now able to create better architecture and more informed estimations due to these training exercises. They got a deeper understanding of how to apply design principles and patterns, as well as improved problem-solving skills. Within the predefined domain covered by our workshops, participants gained increasing knowledge and familiarity with the techniques relevant to building architecture.

In addition, our developers simply came up with new ideas and approaches to software architecture, which should have an effect on their ability to apply them in their daily work. Finally, the sense of community these group trainings offer is something all participants enjoyed.