ThomasCantrell.com Tech Blog

The Harvard Business Review has an excellent article on managing during a recession. After all:

[Susan] Fiske explains: “People pay attention to those who control their outcomes. In an effort to predict and possibly influence what is going to happen to them, people gather information about those with power.” Further, people tend to interpret what they see the boss do in a negative light…. Related studies also show that when people down the pecking order feel threatened by superiors, they become distracted from their work.

The articles advice is for managers to work hard to address four areas:

• Predictability: Give people as much information as you can about what will happen and when….
• Understanding: Explain why the changing you’re implementing are necessary…
• Control: Take a bewildering challenge and break it down into “small win” opportunities.
• Compassion: … Express empathy and — when appropriate — sorrow for any painful actions that have to be taken.

This article seems to have a strong grasp on the issues. I’ve seen the “cone of silence” where managers don’t talk about the layoffs and keep me in constant stress. However, I’ve also seen managers personally talk to every employee in their department when employment seemed unsure.  It quickly eased the tension. Now that’s good management!

An Oldy But A Goody from Joel on Software:

[P]rogramming tasks take so long to task switch. I feel like when I have two programming projects on my plate at once, the task switch time is something like 6 hours. In an 8-hour day, that means multitasking reduces my productivity to 2 hours per day. Pretty dismal.

While this is eight years old, it is still extremely true. It’s good to remember really how inefficient it is to try to do multiple things while programming. 

In my world, my responsibilities are spread over enough topics that I can easily switch between things and take over a day to “task switch.” That’s why it’s really good to try to focus on one main thing. Now if I could only control outside interruptions…

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.