Improving software architecture through – murder

Marianne Bellotti, a software developer with more than 20 years of experience and the author of Kill It with Fire, recently spoke about it at the Craft Conference.
Read on for the most important facts from this lecture, which can help IT industry leaders and software architects better organize and work efficiently on large projects.

Managing the fear of making mistakes

“Murder Boards” have a long history in politics and military operations, but they actually started at NASA as part of the engineering process.

In highly risk-averse, technical endeavors where extreme efforts are made to prevent mistakes (e.g., satellite operations), murder boards aggressively review, without constraint or pleasantries, a situation’s problem, assumptions, constraints, mitigations, and proposed solution.

The board’s goal is to kill the well-prepared proposal on technical merit; holding back even the least suspicion of a problem is not tolerated.

Such argumentative murder boards consist of many subject matter experts of the specific system under review and of all interfacing systems.

Working on large software projects also requires making significant and strategic decisions, and the fear of making mistakes is an integral part of the entire process. That’s precisely why Marianne adds that building and deploying technology is inherently very risky, and so much engineering management is managing fear on a team. Also, fear changes the decisions people make.

Murder boards are not code reviews

That is precisely why, adds Marianne, the Murder Board represents a panel of expertise. This way of knowledge or organization is used when working on and developing one of the projects, which is challenging. It also helps to see how errors can be removed or thrown out while developing large software solutions.

Although the Murder process could be a crucial part of software development, it is definitely not an alternative or different style of code review, a compliance/oversight activity, or a replacement for post-mortems.

When it comes to briefing colleagues regarding the murder board process, it is important that both parties have prior knowledge of the project plan, its historical context, and, in fact, everything that any large organization would do, only applied to the technical area, i.e., the IT industry.

Preventing failures

Marianne says that many did not trust the murder process and were afraid of it, and in fact, one of its leading roles is to protect colleagues from threats and fears that can arise in the demanding process of software development:

It is easiest to design and develop a plan at the beginning. Still, from the moment of checks and iterations until the execution of the plan, the fear meter starts to increase, which is exactly why you should have a murder board prepared in time.

Marianne adds that through good organization based on the murder board, two types of failure can be prevented:

Technical Failure:

• Scenarios where cascading failures will have unpredictable secondary effects;
• Board members: Principal engineers, staff engineers, architects.

Social Capital Failure:

• Embarrassment;
• External but also internal;
• Board members: Business leaders, strategy, legal, marketing/PR.

Best for high-stress/high-fear projects

Marianne also mentioned that one of the surprising benefits of murder boarding is that it can make people feel like their colleagues have their backs. Also, having your decision validated by more senior people can help reinforce a blameless culture if the worst does happen.

Before you set up your murder board, you should have in mind the following:

• I like to give my murder boards a day or two to submit questions to the team;
• The best murder boards will result in an in-depth discussion, so giving the attackers a chance to think through which concerns are the most serious and giving the defenders a hint on what the board might focus on helps everyone.

At the very end of her lecture, Marianne concluded that:

• Murder boards fit very specific situations: High-stress/high-fear events. The events are necessary and unavoidable;
• Opportunity to thoroughly vet plans, but not a code review, Should not be a regular part of the development life cycle;
• Done well, they build trust and confidence and help the team support one another.