It seems for a long while doctors in the 19th century did not wash hands between examining different patients or doing an autopsy resulting in perpetual cross infections and high mortality. One such example is by Doctor Ignaz Semmelweis who found out the link after observing a lot of cases but not before a lot of people losing their lives. The mindset is still the same, people need to be presented with a lot of data before they could take an action without applying the knowledge and reasoning.

Either the data way or highway

I have met my neighbour who is a doctor and he sometimes asks my granny for advice to take care of his child. I asked him “You being a doctor, why are you asking my granny for advice, she can’t even read”. I was in school when I had this conversation, I did not understand at that point. His reply was “Not everything can be found out scientifically, people over time will develop the habit of observing cause and effect, so grandmother’s advice works most of the time”.

There are different ways one can take a decision, data is one of them. There are others are like observation (anecdotes and personal experiences), logical (computing using formulas), hypotheses (works in one case, it should work in another similar case too). The problem with a shiny tool is everyone wants to buy that and then try to find how to use the tool instead of having a place for each one of them. The mindset I observe is that people can afford to be wrong as long as the data supports them. What if the data collected and analyzed is not the right one. People who think that they can solve any problem using data, can you predict the next FIFA world cup winner with a great confidence? Can you program a bot to get 100x returns from stock markets in a year if we can access the necessary hardware and tools?

While data crunching just like multiplying numbers is best left with machines, computers will speed up the rate at which humans can make mistakes. What use is of a knowledge that we extract from data when we don’t have an opinion or a theory on what to expect? Human intelligence should have its space as it is equipped with the most complex computer which is hard to understand how it works.

Just by running behind a method is not going to help, same with running behind the toolset and techniques behind data. One should know what they want to achieve instead of just trying to setup an infrastructure then wish for something to emerge out of it. There is also a rampant misclassification of simple analytics, graphing and time series as data solutions. Let us use all the available tools in the arsenal, not just rely on the shiniest one.

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.