Skip to content

Pitfalls of Software Development: McNamara's Fallacy and the Pitfalls of the AI ​​Era

Software Development's McNamara Fallacy: When Metrics Mislead

Is it dangerous to believe only in numbers? What is the "McNamara fallacy" that you should know about in the age of AI?

Hello, I'm John, an AI technology blogger. When making decisions, how much do you trust "data" or "numbers"? As the saying goes, "numbers don't lie," and objective data is very reliable. But what if "believing only in numbers" could lead to big mistakes?

Today, I would like to talk about the "trap of numbers"."McNamara's fallacy"This is a very important lesson that is useful not only in the world of software development and AI, but also in our work and life.

What is the "McNamara fallacy"?

The McNamara fallacy in a nutshell"The mistake of basing judgments only on what can be measured and completely ignoring what cannot be measured, leading to erroneous conclusions"You read it right!

The origin of this phrase comes from Robert McNamara, who was the US Secretary of Defense in the 1960s. He was originally the president of the major automobile manufacturer Ford and was a very successful businessman. His strength was his management method based on thorough data analysis and statistics.

When he became Secretary of Defense, he brought this approach to his command of the Vietnam War. He believed that "what cannot be measured should not be taken into consideration when making decisions," and he used only measurable data, or "numbers," as indicators of success. A prime example of this was the "enemy body count." He judged that the higher this number, the more the war was being won.

However, as we all know, the outcome of a war is not that simple. There are many factors that cannot be measured in numbers, such as the morale of the soldiers, the support of the people, and the geographical issues of the area. By ignoring these factors and chasing only the numbers, they made the wrong decision... This bitter lesson gave rise to the term "McNamara's fallacy."

Why is it now considered a danger in the world of software development?

You may be thinking, "Okay, I understand the story about the war, but what does that have to do with software development today?" In fact, the author of the original article warns that the current IT industry is prone to falling into this "McNamara fallacy."

The reason is,It's now surprisingly easy to measure software development.It is.

For example, many development teams now use a system called "Git" to manage program blueprints (source code). Many useful tools have been developed to analyze Git data. These tools allow managers to see detailed statistics about their team's activities.

  • Deploy frequency:How often are new features and fixes delivered to users?
  • Pull request review times:How long did it take for the code you wrote to be checked by your colleagues and given the OK?
  • Cycle time:The period of time from when an idea for a feature comes up to when users can actually use it.

These metrics are very useful for finding out where the flow of work in your team is stalled (bottlenecks). They are very useful, aren't they? But here's the catch. By making the numbers so easy to see,We tend to chase only "easy-to-read numbers" and overlook the more important "things that cannot be measured by numbers."

Software development is not something you do alone, but like a team sport. In baseball, the number of hits and the earned run average are important, but in the end, it's the "invisible forces" like the team atmosphere and the trust between the players that determine whether or not a team wins. It's the same thing.

"What's truly important" cannot be measured by numbers

So, what are the "important things that cannot be measured in numbers" in software development?

  • Ability to write "good code":Experienced engineers know that "this is good code that is easy to read and likely to be easy to modify in the future," but it's (currently) very hard to put an objective score on how "good" is.
  • Good teamwork:Contributions such as "When that person is around, the atmosphere in the team becomes brighter" or "When someone is in trouble, there is someone who naturally lends a helping hand" will not show up in any data.
  • Team Morale:Are your team members passionate about their work? Are they burned out? Team morale is one of the most important factors that directly affect the quality and speed of your project.

How would you feel if your boss just looked at reports of numbers and said, "Your team has deployed 10% less this month?" You might feel demotivated because you think, "They don't see how hard we're working and how hard we're trying to solve difficult problems." No one wants to be treated as a number on a spreadsheet.

Find the right balance between data and intuition

Of course, this article is not saying to "ignore data!" Data analysis tools are powerful weapons for understanding problems objectively. There are many good indicators, such as DORA metrics (a set of indicators proposed by Google and others to measure the performance of development teams).

The important thing isFocus on both "what the numbers tell us" and "what the numbers never show"It is that.

If you look at the data and think, "Oh?", talk to your team members. Listen to the expressions and tone of voice of the team members that don't appear in the numbers. What is really important for managers and leaders is not only the ability to interpret graphs, but also to sense the "atmosphere" of the team and have the courage to trust your own intuition.

A comment from the author

This "McNamara fallacy" is not limited to software development. We are always surrounded by numbers, such as test scores, sales results, and the number of "likes" on social media. However, most of the things that truly enrich our lives, such as friendship, passion, and creativity, are not measurable. I was reminded that it is necessary to take time to look away from the numbers and pay attention to the "important things that cannot be seen."

This article is based on the following original articles and is summarized from the author's perspective:
Software development meets the McNamara Fallacy

Related posts

Leave a comment

There is no sure that your email address is published. Required fields are marked