Reducing Errors in the Workplace: The 3 Golden Rules

This article is an excerpt from the Shortform book guide to "The Mythical Man-Month" by Frederick Brooks. Shortform has the world's best summaries and analyses of books you should be reading.

Like this article? Sign up for a free trial here.

What are the best ways to plan for reducing errors in the workplace? What do experts recommend?

The Mythical Man-Month by Frederick P. Brooks offers guidance to managers leading large teams, especially teams coordinating detail-oriented projects with lots of moving parts. In the book, Brooks explains how to manage the inevitable errors that arise from managing teams performing complex tasks.

Keep reading to learn Brooks’s three rules for reducing errors in the workplace.

How to Reduce Errors in the Workplace

No matter how carefully you plan your project, errors and problems inevitably arise. Regardless of the industry, large projects typically involve a lot of testing, repairing, and perfecting. Reducing errors in the workplace will help to bring your project to completion on time, says Frederick P. Brooks. Brooks led the division of IBM that programmed computer operating systems in the 1960s. He managed over 100 employees to create cutting-edge programs that required an intense degree of coordination: If all the parts didn’t work together correctly, his operating system wouldn’t work. Brooks found that the more parts he needed to coordinate with each other, the more opportunities there were for errors.

Below, we’ll explain Brooks’s three golden rules for reducing errors in the workplace, based on the advice from his book The Mythical Man-Month.

Rule #1: Plan to Throw Out the First Draft

Brooks argues that you should expect to discard your first attempt at your project and treat it as a learning opportunity. He cautions against sinking time and effort into fixing your first draft at all. In his experience at IBM, there were so many errors in the first attempt, that it was more efficient to simply learn from the process, cut his losses, and begin fresh again. Therefore, to apply his advice for reducing errors to your own workplace, Brooks advises you to treat your first draft of the entire project as a trial run.

Reducing Complexity in the First Draft

In later editions of the book, Brooks changed his mind about throwing out the first draft after discovering a new process that made this unnecessary. After leaving IBM, Brooks became a computer science professor, where he was influenced by many of the ideas of his close friend, programmer David Parnas. Parnas introduced Brooks to a new process in which one “grew” the program from the middle out.

The process required drawing a distinction between a program’s core functions and its ancillary functions. Core functions are foundational to a program’s operations, whereas ancillary functions are the added features built on that foundation. If you imagine your computer program as a tree, the core functions are like the roots and the trunk, whereas the ancillary functions are like the branches and leaves.

In Parnas’s strategy, the core functions would be programmed first and tested independently before moving on to the program’s ancillary functions—like growing the trunk before the branches. In Brooks’s previous process, the first draft would be a complete tree: branches, leaves, and trunk. Parnas’s process reduced complexity by reducing the number of components that need to work together in the first draft. Once Brooks adopted this strategy, he no longer found it necessary to throw out the entire first draft.

Rule #2: Expect to Create Additional Errors

One of the most vexing parts of software development is that repairing errors comes with the risk of adding new errors, because fixing code requires changing it. Once you change something, you always run the risk that it won’t coordinate as well with all the other components. Brooks offers two main takeaways.

1. You will reach a point where repairing and debugging provides diminishing returns. There’s no value in polishing a program to perfection forever because your project can never be perfect. To apply this logic to your own workplace—plan on cutting your losses eventually and deciding when the project is good enough.

2. Programs that are patched after they hit the market will slowly degrade. As the programmers publish new patches—repairs introduced after the software has already been published—they will continue introducing new errors. Brooks asserts that patched software naturally disintegrates because every patch runs the risk of making it worse. Therefore, in your own workplace, he advises you to plan on eventually replacing your product instead of fixing it forever.

What Is The Law of Diminishing Returns?

Managers in all disciplines must think about the law of diminishing returns in deciding on the optimal time and effort to invest into repairing errors. Economists provide clarity about the law of diminishing returns: a microeconomic principle that states that there is an optimal threshold of investment, beyond which you start getting less and less out of your investment.

For example, let’s say a farmer living in an arid climate installs a new irrigation system to water their crops. Because the plants had been living under such dry conditions before, this irrigation system leads to enormous yields the first year. So the next year, the farmer installs a second irrigation system hoping to repeat the results. Instead, the crop yield stays the same. Because their first irrigation system hit the optimal threshold of water for their field, adding more water now results in diminishing returns.

Applying this logic to Brooks’s theories of programming, we see that there is an optimal threshold of time and effort to invest in debugging. Continuing to repair errors will keep introducing additional errors, and once the optimal threshold is passed, additional repair will no longer improve the product. Similarly, there is an optimal threshold for patching and updating software after it has reached the market. Beyond that threshold, your time and effort will be better spent simply designing the next version of the software.

Rule #3: Don’t Build Something You Can Buy

Brooks’s last piece of advice for reducing errors in the workplace as well as overcoming the challenges of managing complex projects is simply not to do it at all. Because of the inherent challenges and complexity involved in certain projects, often you can save your company a lot of time by simply buying something off the shelf instead of producing it yourself. Brooks cautions you to consider what actually needs to be made in-house, and where you can cut time, cost, and labor by making a simple purchase.

When Should You Outsource?

Brooks advises you to avoid complicated projects when they are unnecessary. Sometimes, the best way to reduce errors in the workplace is to outsource a project to experts. But how do you know when it’s time to find an outside contractor? Business experts offer four recommendations on when to outsource:

1. Your team is at maximum capacity. If your employees already have too much on their plate, consider approaching them to see what tasks they’d like to delegate elsewhere.

2. Your company lacks certain skills or specializations. It’s a good idea to outsource when you don’t have the staff to deal with a highly specialized problem or task.

3. There’s no advantage to doing it in-house. Consider what competitive advantage you gain by doing something in-house. If it’s hard to come up with one, you might want to outsource.

4. Scaling up too fast. If you’re a small startup growing quickly and find that you can’t keep up with demand, you may want to start delegating.

Reducing Errors in the Workplace: The 3 Golden Rules