ThomasCantrell.com Tech Blog

One of the members of my engineering team died suddenly a few weeks ago. He was a brilliant engineer and only 21.

To respect the family, I am not posting much more information. However, I want still to take the time to talk about the contemplative journey caused by his untimely death.

As software engineers, we are passionate about technology. In embedded networking, we are passionate about the intricacies of the bits and bytes that make up communication.Most of our conversation is driven by technological talk.

Yet, we are foremost people. We are a community of workers, people who go home to their friends and family. We are a people that have dreams and goals, people who have a life beyond the bounds of work.

I remember the day a couple of weeks ago when his death was announced. After the initial shock had worn off, sadly there were still meetings and projects that were due. I tried to take time over lunch to reflect, but it’s hard to know how to reconcile the tasks of works with taking time to reflect on the engineer’s life.

As engineers, we build a competency in talking to each other about technical issues. However, it is much harder to talk about life and death with your co-workers. We look at each other not knowing exactly what to say. Life is much harder than bits and bytes.

From these sad events, I have been reminded of this firm conclusion: the value of a single human life dwarfs the value of the technology that we continuously dialog about.

As humans we tend to optimize our experience in ways we think will bring about the most favorable outcome. As workers we tend to work in ways which we enjoy and we believe we will be rewarded. As software engineers we tend to work in ways that we believe will get the best possible product to the customer and the best possible performance review for our work.

Software release processes take a long amount of time. They can take days, but often take multiple months or even years. However, from my own observation there is one easy way to slow down a software release: change the rules of the game in the release process.

For example, a software release enters the QA department with a certain set of features. While in QA, it is decided that an “essential feature” is missing. The software release is then ejected from QA to move to further development. Once the development is done it enters QA again. This time it releases, months late to the customer.

The same scenario could have played differently. The software could have entered QA. When the “essential feature” conversations, the software product proceeds through QA uninterrupted and releases. Then the “essential feature” could be added to the product and released in a seperate cycle. This way the customer gets the development they already desire, as well as the addition of the “essential feature” when it releases later.

What happened in the first example, is that the rules of the release were changed while in the release process. This caused the release to stall while every member of the team readjusted for the new rules. If the release had simply kept a consistent rule-set, then it would have gone out devoid of the “essential feature.” Once the product had shipped, a new process playing with the new rules would have commenced.

I believe that one of the most demoralizing things for an engineer to get stuck in a rule change situation. They hear that their code is going to ship in a few weeks. This causes them to rank up, and creates a sense of urgency. The urgency is driven by the reward of releasing their code to the customer. When the rules change, their code does not release. They then slow down to adapt to the new rule-set. However, now something is lost. They cannot find it in themselves to ramp up again for the next release. The light at the end of the tunnel has grown dim.

In conclusion, I believe that one key premise for software releases is change as little as possible towards the end of the release, especially when the product is in QA. It’s just dangerous to change the rules of the release game.