Lecture
Kata is a Japanese word meaning «form». It refers to a carefully choreographed sequence of movements in the martial arts. Kata can also be practised in groups and in unison during training. In Japanese martial arts, it is practised as a way of memorising and perfecting the movements being performed.
More recently, the word «kata» has come to be used in English in a broader or figurative sense, denoting any basic form, routine or pattern of behaviour practised to varying levels of mastery.
In programming, a kata is a small exercise that a developer performs regularly in order to sharpen their skills. The term comes from the martial arts, where a kata is a repeatable sequence of movements that helps bring technique to the point of automatism. In coding the idea is similar: a programmer solves small problems over and over again, improving their way of thinking, the quality of their code and their speed of work.
A code kata is not merely an algorithmic problem. The main goal is not always to “get the right answer”. What matters far more is the process itself: how the developer writes the code, how they break the problem into parts, how they name variables, how they test the solution and how they make the code cleaner after the first working version.
For example, classic katas might include problems such as FizzBuzz, String Calculator, Bowling Game, Roman Numerals or Conway’s Game of Life. These exercises are simple enough that you do not spend much time understanding the requirements, yet interesting enough to train design, testing and refactoring.
Katas help develop skills that rarely improve on their own. When a programmer works only on production tasks, they are often constrained by deadlines, business requirements and existing code. In a kata you can experiment freely: try a different approach, apply TDD, rewrite the solution in a functional style or compare several architectural options.
Regular practice helps you:
It is better to choose small exercises that can be completed in 20–60 minutes. The point is not just to solve the problem once, but to come back to it several times. On each repetition you can change the goal: today solve it with TDD, tomorrow write the simplest possible implementation, then improve the class structure or try another language.
A good approach looks like this: first write a minimal working solution, then cover it with tests, and after that improve the code. Do not aim for perfect architecture straight away. A kata is useful precisely because it lets you go through the full development cycle in miniature: understanding the problem, coding, testing, fixing bugs and refactoring.
Code katas are often used together with TDD — test-driven development. In TDD the programmer first writes a failing test, then adds the minimal code needed to make it pass, and only then improves the solution. This cycle is known as “red-green-refactor”.
Katas are an excellent fit for TDD because the problems are small and easy to grasp. The developer can focus not on the complexity of the domain but on discipline: writing small tests, moving in short steps and not overcomplicating the code prematurely.
For newcomers, katas are a way to get hands-on practice and become comfortable with the syntax of a language. They help you understand basic data structures, conditionals, loops, functions and tests.
For experienced developers, katas are useful in a different way. They allow you to train architectural thinking, try out new tools, improve your coding style and stay in professional shape. Even a simple problem can prove valuable if you solve it under a new constraint: without loops, using recursion only, applying design patterns or working in a different programming paradigm.
The main mistake is treating a kata as a speed contest. A fast solution is not always a good solution. Another mistake is taking on problems that are too complex. If an exercise takes several days, it is more of a study project than a kata.
You should also avoid simply copying other people’s solutions. It is far more useful to try it yourself first, then compare approaches and understand why another option might be better.
Katas in software architecture
In software development, architecture often seems like an area that cannot really be practised. You can write code every day, you can add tests in a live project, you can solve algorithms on dedicated platforms. But you are rarely given the chance to design the architecture of a large product “from a blank sheet”. In reality, an architect more often works with an existing system, business constraints, legacy code, a lack of time and trade-offs.
This is exactly why architecture katas are useful for developers, team leads and architects. These are training exercises in which participants design the architecture of a hypothetical system within a limited time. The goal is not to produce a perfect diagram, but to learn to ask the right questions, see the risks, choose trade-offs and explain your decisions.
Real architecture rarely emerges under sterile conditions. Usually the system already exists, the team has already chosen the stack, the business has already set deadlines, and some decisions were made many years ago. An architect does not always “build a house from scratch”; more often they repair, extend and reinforce a building that people already live in.
Moreover, architectural decisions have a long feedback cycle. A bug in a function can be spotted within minutes. A mistake in the architecture is sometimes only visible months later: the system scales poorly, changes become expensive, teams start getting in each other’s way, and operations turn into constant firefighting.
Because of this, an architect needs a separate form of practice. That is precisely the role architecture katas play.
An architecture kata is a short exercise in designing the architecture of a software system. Participants are given a product description, business context, constraints, quality requirements and a number of uncertainties. The team must then propose an architectural solution and defend it.
For instance, a brief might read as follows:
Design a platform for booking medical consultations online. The system must support doctors, patients, schedules, payments, video calls and notifications. In the first year, launch is expected in a single country, but an international rollout is planned within two years.
At first glance this is an ordinary technical specification. But the architect’s job is not simply to draw microservices. They have to work out which requirements are critical: data security, fault tolerance, scaling, integrations, legal constraints, time to market, cost of support.
A study project usually ends with code. An architecture kata more often ends with a decision, a diagram and a rationale. What matters is not only “what we will build” but also “why this way”.
A good exercise should include:
In architecture there are almost no decisions without downsides. That is why a kata teaches you not to look for the “perfect architecture”, but to choose an architecture suited to the specific context.
Such exercises are best done in a small group of 3–6 people. One person can play the role of the customer or moderator, while the rest form the architecture team.
The process usually looks like this:
Limiting the time is particularly useful. For example, allow 60–90 minutes for design and 15 minutes for the presentation. A time limit forces you to focus on what matters most, as is often the case in real work.
Such exercises develop more than just technical thinking. It is important for an architect to be able to work with uncertainty. They often make decisions with incomplete information, which means they must be able to state their assumptions.
Architecture katas train:
This is especially important because architecture is not only about diagrams. It is about decisions that affect the cost of change, development speed and the resilience of the system.
The task: design a food delivery system for a city with a population of 2 million.
Context:
A startup wants to reach the market quickly. At launch it plans for 50 restaurants, 200 couriers and up to 10,000 orders a day. Within a year the company wants to scale to several cities.
Features:
The user can choose a restaurant, place an order, pay for it, track the courier on a map and receive notifications. The restaurant must accept or reject the order. The courier must receive suitable orders and update the delivery status.
Qualities:
The system must be available at peak hours, process payments correctly, never lose orders, update the delivery status quickly and allow new cities to be added.
Questions for the architect:
There is no single correct answer here. One team might propose a modular monolith with queues for critical events. Another, a set of microservices. A third, a hybrid approach. What matters is that the solution fits the business context and the constraints.
Experienced architects often work within a single domain: fintech, e-commerce, healthcare, telecom, enterprise systems. Katas let you step outside your usual environment and practise on other types of problems.
For example, an architect of banking systems might try designing a high-load gaming platform. An e-commerce architect could work on an IoT monitoring system. This broadens your set of architectural patterns and helps you avoid applying the same approach to every problem.
Architecture katas work well as a team practice. Developers begin to understand better why architectural decisions are made for reasons beyond the “elegance” of a diagram. Business analysts see which requirements need clarifying. Testers can raise questions about observability, failures and quality earlier.
This practice helps build a shared language within the team. After a few katas, people start talking more precisely about context boundaries, risks, load, SLAs, technical debt and the cost of change.
One of the main benefits of architecture katas is that they teach you to make trade-offs explicit. Microservices, for example, can give you independent scaling and team autonomy, but they add infrastructure complexity, network failures, distributed transactions and the difficulty of observability.
A monolith may be faster and cheaper at the start, but with poor modularity it will become hard to change over time. An event-driven approach helps decouple components, but complicates debugging and data consistency.
A good architect does not simply pick a technology. They explain the price of the choice.
Architecture katas are needed because real architecture is rarely designed under ideal conditions and even more rarely created from scratch. In most projects the architect works with legacy, constraints, risks and incomplete information.
Katas provide a safe training environment. In them you can make mistakes, argue, compare approaches, try different architectural styles and learn to defend your decisions. This practice is especially valuable for architects, team leads and senior developers, for whom it is important to develop not only technical knowledge but also systems thinking.
Regular architecture katas help you prepare for real architectural work: not for drawing pretty diagrams, but for making difficult decisions under uncertainty.
Katas in programming are a simple yet effective form of professional training. They help you not only solve problems but also write higher-quality, clearer and more reliable code. As in sport or music, regular deliberate practice makes a developer stronger. Even 20 minutes of kata a few times a week can noticeably improve your programming skills and your confidence in working with code.
Comments