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.

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.

COVID brought two kinds of people out. Those who wanted to help others in whichever way possible and those who wanted to make use of this a business opportunity to earn more. Black markets opened up for masks, gloves and sanitizers. For things where there is no MRP, prices sky rocketed for a while before supply caught on. I thought it was only small businesses who were trying to make quick money on this but it was there for a lot of big businesses and unicorns who jumped on this wave.

For example, I had seen status messages of people exchanging their points for donating oxygen facilitated by a fintech. This fintech was making people put up in their statuses for donating tens of thousand of liters of oxygen for their accumulated points, which made people very happy and give the company a much needed free promotion. But on a simple fact finding they are not giving out liquid oxygen but they were giving out numbers in regular atmospheric pressure.

A simple misinformation and not telling all the facts just drove people to freely promote the company. Oxygen is not at all costly, 20+% of atmosphere is oxygen, if you reverse the process of nitrogen concentrators that are used for filling car tyres you get 99% oxygen. For the record, a kilogram of LPG will not cost more than 60 rupees. A kilogram of oxygen is roughly 700 litres and that is barely enough for an hour for a covid patient, 1 litre of liquid oxygen will expand to around 860 litres of breathable oxygen. Government recently capped prices for refilling liquid oxygen at 25.71 rupees + GST per Cubic metre (1000 litres of liquid oxygen) which is around 86000 litres of breathable oxygen.

I have seen people putting up status messages on linkedin and whatsapp saying they donated 100,000 litres of oxygen and they feel proud about it, you are misled. You ended up donating about 40 rupees. There are more companies who are trying to ride the wave, we may not even be able to notice and will fall for their marketing skills.

It is the work of the majority of the good hearted people that still keeps us going. Do not get carried away with the marketing, help for the right set of people.