dagblog.
← Archive

Mikhail Kalashnikov's legacy for software development

Roman Pichlík ·

This article picks up a thread from the informal military series Banter and I have been writing. In his latest installment, What companies can learn from the military, part 2, he wrote about uniforms. I want to take up a current subject, the death of Mikhail Kalashnikov [1.], designer of the AK-47 assault rifle, known for short as the Kalashnikov, which even made it onto the flag of Mozambique. I think Karel Minařík first drew the parallel between software development and the design of the AK-47 [2.]. The AK-47's design can inspire the kind of reliable software design I talk and write about under the Cynical Software banner.

Making a virtue of necessity

Kalashnikov based his design on experience and on what Soviet industry could do at the time, when it was virtually impossible to make the individual components of a weapon precisely to size. The barrel and bolt had to fit exactly, but the remaining components could vary from the specified dimensions. As a World War II veteran, he expected a hammer to be the only repair tool available in combat [3.]. The weapon's design was very simple, allowing it to be manufactured cheaply, another necessity given the economic reality of the Soviet Union at the time. A simple, forgiving design made it reliable without requiring maintenance. Necessity became a virtue. The weapon went on to serve successfully in practically every war after World War II and became legendary and popular because of its reliability. Manufacturing tolerances made it less accurate than the rival M16 assault rifle, but its simplicity and reliability more than made up for that.

The success and superiority of the design are also borne out by its licensed manufacture in countries beyond the Warsaw Pact. The Israeli Galil and Finnish Valmet, for example, were based on it [4.]. Though the design is more than sixty years old, it has seen only minor changes. In that time no assault rifle design has substantially surpassed the AK-47 [6.].

Mikhail Kalashnikov's legacy

What can we take from the design of the AK-47 into software development? There are several areas where it can inspire us.

Like many inventors, Kalashnikov did not have a sudden flash of insight out of nowhere. He had studied a range of rifle and submachine gun designs in common use during World War II. His combat experience helped him see what was critical to the functioning of an assault rifle. Incidentally, he also designed a shot counter for a tank gun and a modification to the Tokarev pistol for firing from inside a tank [3.]. When you start designing a system, chances are good that someone has done something similar before. Study those solutions and see what you can learn from them. Kalashnikov didn't invent anything new in isolation. He brought existing ideas together into a new whole and accounted for the Soviet Union's technical limitations at the time.

He knew that a simple design would make production cheap. The advantages of simplicity are clear: the design is easy to understand and implement, and when something breaks it's easy to fix. His design was a textbook example of the KISS principle. A simple design leaves fewer things that can break. Software development, by contrast, often emphasizes features at the expense of operating costs. Unfortunately, the ultimate cost of maintaining the entire solution is hidden. The American M16 had reliability problems during the Vietnam War because it was expected to be maintained, and someone forgot to supply cleaning kits. Kalashnikov, on the other hand, assumed his weapon would receive very little maintenance.

Whenever we're designing a system and need to remove stale data, at least one proposal involves some kind of garbage collector. The classic version is usually a cron job. Unfortunately, it works like that missing M16 cleaning rod unless you enable it on every installation, ensure only one instance runs even in a cluster, keep it from consuming too much memory, and ensure it finishes before the next scheduled run. There are a lot of ifs. That's why I always prefer designs where stale data expires automatically. MongoDB, for example, supports capped collections that discard old data automatically.

Loose manufacturing tolerances and the design they prompted are roughly analogous to loose coupling between the parts of a system [5.]. Loosely coupled components don't depend directly on each other's implementation details. This makes it easy to swap one implementation for another without affecting the whole. Loose coupling also means, or should mean, that the system continues working when the conditions around it change. You want your rifle to work even after a camel has just peed on it, and you want your system to work even when one component has problems. Expect specifications to be incomplete and implementations to fall short of them. Design a system that tolerates faults by its very nature, just as Kalashnikov designed for them.

It's hard to design such a system if you assume it will run in a perfectly reliable environment. From combat, Kalashnikov knew the environment in which his weapon would be used. He knew what situations might arise and designed for them. To improve your design and execution, you need firsthand experience of the setting in which your system will be deployed. In software development, try operating your own system for a few weeks or switch into DevOps mode.

Perhaps Mikhail Kalashnikov's greatest legacy is the idea that a system doesn't need a thousand and one features. It needs to do exactly what people use it for, and to do it reliably.

Update: I also recommend What designers can learn from the AK-47 by Scott Berkun, author of the excellent book The Myths of Innovation.

References

Medium version

Related articles

Related CZ Podcast episodes