There are different kinds of sports when you classify on how do you train people for the sport. There are one shot sports like archery, athletics with a single focussed task on winning. Then there are individual multi shot sports and team sports.

Mental and Physical fitness is a pre-requisite for any sport for we will not talk much about it; eating, exercising and sleeping well will be part of any training. For majority of the one short sports the line is blurred between drills, practices and performances. You don’t want the players to think in a one shot game, they have to behave as trained by the coach. For years they will be doing things that will help them in just one thing, to take the best shot at their sport every time they hit the track.

The training changes from when moving from one shot to multi shot sports. Sports were individuals compete against another head to head falls in this category. Here the difference starts to arrive between drills, practice and performance. Drills for a tennis player is to work on weak areas and improvise on certain shots until it becomes muscle memory, practice is to have a fun game with another athlete to practice the shots and learn in a match setting. If we note that practice matches without drills will not help a tennis player get stronger with their shots and having drills alone without practice will not help them win matches.

Then the added layer of complexity for team sports where you need drills & practices for sure but there has to be a game plan that is a shared understanding among all the players, camaraderie within the team, post match analysis. The method of training a sportsperson for one shot sports won’t work in a multi shot team sport setting.

If we draw parallels to software development, it falls close to the team sports category. Yet a lot of executives design the environment to groom people for one shot sports. Many of the developer training lessons concentrate on development as if all three drills, practice and performance are all the same and the more someone keeps doing the more experienced they get.

Drills in software development are activities like code katas and architectural katas, Game plans are activities like planning meetings and retrospectives, Practice matches are activities like group refactoring/coding sessions and hackathons; also not to forget to educate software engineers to take care of the most neglected part which is their fitness. Many of the executives I had interacted with sadly neglect all these aspects and are worried only about the delivery part of software engineering. Engineering’s effectiveness comes only when the skills are improved using all the types of activities not just exposure to development and production problems.

Airplanes are good to learn about rigour in engineering as well as airpersonship. The quote ‘Airspeed is life and altitude is insurance’ is ingrained into every pilot’s head. Every decision during a flight can be qualified using this statement. Having the right airspeed means, it is a safe flight in the intended direction. Having enough altitude means, there is enough time to recover if something goes wrong.

I was always looking for one such statement for software craftspersonship, though we had agile manifesto, camp site rules etc there was not much that can actually showcase the excellence of a software project. When I thought about the 4 key metrics from the book Accelerate and the airpersonship side by side, an idea struck me as to why not the same statement be applicable for the software craftspersonship as well.

Airspeed can be Deployment frequency and Lead time; Altitude can be MTTR (Mean time to restore) and Change fail percentange.

Airspeed determines how fast can you bring an idea to production and how often can you do it. Altitude means how much can you go wrong and how much of a leeway do you have if things go wrong.

Why not see the 4 key metrics this way? Start looking for Airspeed and Altitude.

Contrary to the name given, firefighters wish to prevent fires rather than fight fires. A lot of people in fire safety always think about prevention first then only about fighting methods. I had briefly worked in the space of safety systems, for an office building many fire safety protocols are in place like monitoring, automated extinguishing, ease of access, education etc. A fire is best prevented or extinguished when it is too small to cause any damage.

Software industry on the other hand idolizes fire fighting metaphorically. We have progressed with tech so much that instead spending energy on monitoring and alerting alone, there are systems which can scale up and down based on traffic, restart itself when not responding, retry when messages fail to deliver etc without manual intervention.

Photo by Adonyi Gu00e1bor on Pexels.com

With developers also taking up operations, they are equipped with power to take the call on how to design and run the application. Building a resilient system takes deliberate effort and often have to think about how will the system perform under some conditions. It can’t be caught with unit & integration test cases easily, may be performance tests can catch but it is often not built in the continuous delivery pipeline.

Let us take a scenario, a solution will take about 5 days to introduce some functionality in two different layers to take it to prod but the solution will be very resilient with very less chance of failure versus another solution that can be developed and deployed in a day but it has to be manual scaled up and down depending on traffic situations.


For a reader the solution 1 may look obvious when looking in isolation, but for a set of people who are constantly developing and operating software will not give a second thought to understand the repercussions of solution 2 and may end up taking it, so that there is less work on their plate.

How can we avoid this? Akin to fire prevention we have to set architectural and design decisions that can keep resiliency and self healing as primary considerations for an established system. This can be relaxed for products that are looking for a market fitment, which can be more relaxed compared to an established product.

In one of the situations I was asked when I pointed out a similar problem “What is wrong? I am anyways monitoring, I will go ahead and fix as soon as the alert comes”. I replied “By the time you fought the fire, you already lost some business to competition and also ended spending more money during operations than developing and taking to market”. When people did a simple math they understood the magnitude of it.