Posts

by on

A lot of people quote about Henry Ford’s remark, “If I ask my customers what they wanted, they will say faster horses”. We do not know if he really said those words but it is true that many of the ideas will always be incremental and not inventive, be it technology or ways of working.

If you ask bosses what they wan’t, everyone unanimously says “Longer working hours” especially more vehemently in the software development industry. My observation has been that with lots of automations and tech abstractions, the time taken to develop software has come down by a few magnitudes, compared to what it was a decade ago. What needed large teams with extensive management overhead can be done with smaller teams with fewer oversight.

In mature domains like mechanical and civil, breakthroughs are very less frequent; hence templating the work into easy to do steps that are verifiable by non techies is very productive. An abstract requirement will be translated to actionable steps, broken down into units of work and assigned to people to complete. Once the task is complete, it is very easy to verify by anyone else and the end of construction phase is typically the end of the project. It makes things rigid and predictable, so it has a linear relationship between number of people, number of hours and dependencies.

Software development on the other hand is very difficult to convert from abstract to concrete, any infusion of rigidity risks not getting the intended outcome. The combination of ever improving tech landscape, difficulty in communicating what a working software should do, the nature of knowledge work which degrades when stressed, makes it very hard to have a proven relationship with working hours, number of lines of code and number of people.

Photo by Tara Winstead on Pexels.com

When dealing in a dynamic environment, there is more than one way of doing things, sometimes exponentially time saving ways can be found if we strive to make the design simple. One personal example I had was to write a program to convert roman numbers to decimal. I wanted to shake off the inertia and start writing code, I dived deep into the code thinking in terms of objects, writing a lot of tests and completed it after a few hours when I was convinced that the solution is complete and clean. The next day I realised that I was constrained by the need to keep going, that I never questioned if my solution could be simpler. I just spent 20-30 minutes to rewrite it in functional paradigm and got that done under 10 lines of code in one file which was 100+ lines across multiple files. For an outsider, thinking hard about the problem looks like inactivity, wasting time and not showing urgency; to me it came down to a super simple solution that is very easily be read and maintained by others.

Bosses are often tuned to look for urgency and activity as indicators of productivity. Also in the software service industry irrespective of the productivity, the number of hours billed directly impact profits; hence bosses love long working hours. In the software product industry though billing hours don’t matter a lot, the apparent busyness of people is expected. As a result, no major improvements happen as it is always business as usual sometimes even slowing down overall, creating physically and mentally unfit individuals over the long run.

On the other hand if teams are given freehand, then they also tend to extend the thinking phase into analysis paralysis. This can be broken down by mandating outcomes and impact on fixed timelines than output and effort. It is an art and takes a determined effort to build high performing teams that keep punching above their weight. The easy way out is demanding long working hours.

If you are engaging a knowledge worker on physical effort, then you are buying into mediocrity

by on

Shift left was applied to testing and then the testing scope which was initially functional expanded to include performance, security and resilience. So far it is fine, the problem it brings is when the experience aspect is shifted to the extreme left. This ends up with product having endless loops of perfecting the wireframes and experience aspects to get a perfect shot at the finished product.

Imaging you are playing paintball, you have to shoot down very very fast erratically moving drones. You get two options, (1) a gun which can be reloaded as many times as you want and fire in quick succession but needs 2-3 hits to take down a drone, (2) a gun which can be reloaded only once in a few minutes and takes down a drone in 1 hit. If you are given 10 minutes and you win based on how many drones you take down which would you prefer. If you prefer second, then you have shifted everything to the left without the option to learn from your misfires.

Shift left should be for the delivery mechanism. Functionality, security, performance, resilience all should be tested and if at all they fail should fail very very early, closer to the time the code was committed. Along with this an experimental and dark release setup that can be used to learn user behaviour & adoption. This helps the product send umpteen changes to the end user and get the one that works to remain in production.

There is a lot of value in UX research, paper prototype, wireframes and illustrations but when shift left is applied to this, then each iteration and increment becomes very expensive and forces people to figure out as many variables as they want, which is not possible to discover until an end user uses the system.

Misfire is a given in product development, if we shift left everything we have less chances to learn from our misfires. We should also optimise to validate the hypothesis with a working software, so an idea should see reach the customer for validation as much as possible.

by on

I have never seen anyone dead from crossing a deadline at work. In literal sense, deadlines are deadly; people die if they cross it yet we use it in our everyday work lives to indicate ETA. I see a persistent need for people to use war metaphors at work to install a sense of urgency. Some examples – Setting up a war room, which is nothing but a cosy meeting room where all stakeholders are present to take a quick decision. Info from the trenches, which is simply getting information from people doing the job. Fire our first salvo, which is releasing the MVP.

War is ugly, even when it has a winner many at times it is pyrrhic. I had interacted with people who had done duty in the military and refugees who have been displaced by war. One word to describe, it is – horrific.

  • War kills and maims people. The worst part is that a good portion of people die or are maimed because of someone else’ decisions. Collateral damage is inevitable
  • There are no rights/justice in a war zone, you get to lose everything and often get displaced if you survive
  • Even basic needs are not available, starvation and diseases are common

Long term ill effects of using these metaphors at work is getting primed to respond only to threats and urgencies not anything else. Many of the workplace issues are because of poor ways of working than poor intent to work from the people.

How to go about work then?

My favourite answer is embrace XP, which treats work as work and people as people. XP helps complex and big goals achievable in simple sustainable and repeatable ways. I also show people the Cynefin framework. It clearly marks how decision making works into 5 different domains. Starts with Clear and progresses to complicated -> complex -> chaotic -> confusion. Below is the image from wikipedia for reference.

War belongs to the chaotic domain, the priority is damage control. Focus is on act and then respond based on what happens, where we learn how to limit our damage. Majority of the work on the other hand either belongs complex or complicated domain. Complex domain is used when building user experience, where we learn what user wants. Complicated domain is used when building automations, where we know what user wants.

By thinking in chaotic terms and using those metaphors we are forced to think of limiting damage not be productive, so ditch the war metaphors at work and start using the terms and metaphors appropriate for the problem domain we are in.