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.

Photo by Andrea Piacquadio on Pexels.com

There is a general consensus that as soon as an idea comes to your mind you should start working on it my making more concrete steps and often used sentence is “Putting idea to paper”. Though it leads to making an action, many times people take an illformed idea to paper. Our mind is awesome when it comes to dimensions, any idea we have it is so easy to visualize and develop. Sometimes we have to let the thoughts ruminate and let the idea evolve before finally putting it onto paper.

Why should it be that way? Because we are not so good at expressing what is in our head either in words or picture. Also there is a risk of getting stuck on what we put to paper because of the sunk cost fallacy. Every new idea that comes up will be very very abstract, if we try to channelize energy in capturing it then it won’t be something that is easily actionable. Very few people will be able to represent on paper what they had in mind, like artists but they rely on their ability to iterate on paper or discard their work if not going in the right direction as they thought about it.

When ideas come out in our mind, it makes sense to capture what the idea is but not the details just in case those ideas come as shower thoughts and can quickly melt away. Once the idea gets planted in our mind, it has to take shape. This is where we jump the gun and try to put it to paper and many times let it slip away.

I have observed ideas to be shaping up in my mind like a bell curve. It usually gets more evolved when I run thought experiments but after a while if I don’t put it to paper it disappears, so I had to put it to concrete plans at the right time else it is of no use. People may argue that this is procrastination and it is encouraging people to postpone their work.

We are very poor in putting a well known idea to paper. Read about this experiment where people were asked to draw a bicycle from memory. It looks like most people who have ridden a bicycle all their life will not be able to draw one even to some degree of making a working prototype out of it.

Any idea is worth putting into iterations inside our great brain which can evolve it in multiple dimensions before it can be put to paper. All we need to know is the right time to put idea to action else it will not take off because of analysis paralysis.