We would have read the story of ‘The conditioned elephant’ where a fully grown up elephant is tied using a small rope but it never tries to break free as it was conditioned as a kid that it cannot break a rope. We humans are also trapped with those constraints that we learned to become helpless. I have some stories during my journey.
When I started to program, access to computers were very limited. I have to write my program in paper, verify it a few times, get it reviewed on paper before getting system time and trying how mine works. Even my first few job interviews, I wrote the programs on paper and my interviewer went through the input and output manually before pursuing my candidature to solve tougher problems using a computer.
What this meant was I learnt the language fundamentals well, I understood many gotchas on the syntax and often I can write 100s of lines without syntax/compilation errors, without referring to any manuals or help articles. My behaviour continued even when I had my own system full time along with internet access. I spent a lot of time understanding in detail before I would claim myself proficient in a specific language or a tool and also refused to use IDE.
Barring a few occasional WOWs, I was slowly slipping into struggle like “The boiling frog“; observed in an experiment that a very gradual raise in temperature can kill a frog without it realising that it is being boiled. My years of conditioning with poor hardware and no internet meant I had to get a fair degree expertise before I could code professionally. While it is a good thing that something forces you to master a topic, the bad thing about this is I learnt to have a delayed feedback about trying new things out. When it came to experiment I used to lag behind as I was more inclined to deep dive instead of fail fast.
Every time someone whom I know coaxes me into changing my ways of working, I was held back by IT policy of “not upgrading the machines until they fail”. For a few years my machines at work never supported anything beyond a simple text editor which reinforced my older ways of working. It was only after an upgrade (I bought my own laptop), I realised the joy of programming in an IDE. For the first time TDD was a breeze and I fell in love with that method but not before wasting a few years in an outdated style.
Every few years information, hardware, connectivity, software is becoming more accessible. It is churning up faster than we can sense and adapt to the new landscape around us. We are often caught up like boiling frogs and stick to our trusted and tried methods at work until a jolt comes externally. New year beginning is always a good time to identify what constraints are we victim to and do they really exist? Every year I keep finding things that are outdated in my style of working and upgrade them. It is not just limited to workplace, it is in every aspect of life. Try finding out, what constraints are holding us back and do they exist?
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.