Additive bias is a cognitive bias that affects our ability to assess the value of candidate solutions to problems. Specifically, it causes us to favor additive solutions — solutions that add components and complexity to solutions we already have. Likewise, it causes us to assess as less valuable subtractive solutions — solutions that have fewer components and which are less complex than solutions already in hand. For more about additive bias, see "Additive Bias…or Not: I," Point Lookout for June 26, 2024.
As noted in my earlier post, additive bias is only one of many possible sources of overly complicated problem solutions. In that post, I posed a realistic scenario in which the additive bias could play a role. I also provided two descriptions of mechanisms in which organizational politics could cause people to favor additive solutions over subtractive solutions.
In this post I describe two other mechanisms unrelated to additive bias, and which can produce overly complicated problem solutions. These two mechanisms are based on assessments of engineers as to the cost of implementing the problem solution. In this scenario I suggest how an engineer could judge that an additive solution might be more easily implemented than a subtractive solution, even though the subtractive solution might appear to be a simpler result.
Two technical phenomena that can lead to asset bloat
Although additive bias can lead to asset bloat, other phenomena can do so as well. Here are two effects that have roots in technology.
As engineers go about their work of adding a capability to an application, they have the usual technical concerns. The must identify what parts of the code need alteration, what parts need to be added, and what parts need to be removed.
Under schedule and budget pressure,engineers must decide how much to
invest in understanding the current
system. Sometimes creating whatever
support the new changes require
is a lower-cost approach.
- The cost of understanding
- Under schedule and budget pressure, engineers must decide how much to invest in understanding how the system now works. Unless the engineers were personally involved in developing the system as it now stands, that task — understanding the system — typically involves study, research, and possibly interviews of the authors of the existing system, if they're available. In some cases, a lower-cost approach involves creating whatever support facility the new changes require, rather than studying the system to determine whether those capabilities are already present in some form, or if so, how to use them.
- The end result, in some cases, is capability duplication that can appear to be the result of additive bias. In reality though, the engineers who do this will have found a way to meet the objective with even less work than would have been required without the duplication of capability. What appears to be additive is actually subtractive from the viewpoint of the engineers doing the work.
- Revalidation
- If our engineers decide to modify module M of the existing system, they might later be required to re-validate M as part of their work. Revalidation can require execution of test suites and evaluation of test results. To perform these operations, some portion of the engineering effort must be allocated to understanding the validation process, possibly extending the validation process, and performing the validation.
- This portion of the effort can act as a deterrent to engineering teams that are considering approaches that involve modifying existing components of the system. To avoid revalidation, some teams elect alternative approaches. Alternative approaches often involve adding new elements that are required only because of the decision not to alter any components that would then require revalidation. The end result then can appear to be consistent with additive bias when it's actually the result of avoiding approaches that would necessitate revalidation.
- It should be noted that in software engineering, at least, approaches that exploit inheritance and polymorphism can limit the need for revalidation.
Last words
These past two posts have provided four examples of mechanisms that cause system maintainers to choose to add components to the systems they maintain. They add these components even though they recognize that alternative subtractive approaches can yield superior outcomes. I hope that those who argue that these additions are evidence for the effects of additive bias can provide quantitative analysis to support their positions. First issue in this series Top Next Issue
Are your projects always (or almost always) late and over budget? Are your project teams plagued by turnover, burnout, and high defect rates? Turn your culture around. Read 52 Tips for Leaders of Project-Oriented Organizations, filled with tips and techniques for organizational leaders. Order Now!
Your comments are welcome
Would you like to see your comments posted here? rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.comSend me your comments by email, or by Web form.About Point Lookout
Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.
This article in its entirety was written by a human being. No machine intelligence was involved in any way.
Point Lookout is a free weekly email newsletter. Browse the archive of past issues. Subscribe for free.
Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.
Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.
Related articles
More articles on Workplace Politics:
- Nasty Questions: II
- In meetings, telemeetings, and email we sometimes ask questions that aren't intended to elicit information.
Rather, they're indirect attacks intended to advance the questioner's political agenda. Here's part
two of a catalog of some favorite tactics.
- Managing Non-Content Risks: I
- When project teams and their sponsors manage risk, they usually focus on those risks most closely associated
with the tasks — content risks. Meanwhile, other risks — non-content risks — get less
attention. Among these are risks related to the processes and politics by which the organization gets
things done.
- That Was a Yes-or-No Question: II
- When, in the presence of others, someone asks you "a simple yes or no" question, beware. Chances
are that you're confronting a trap. Here's Part II of a set of suggestions for dealing with the yes-or-no
trap.
- Confirmation Bias and Myside Bias
- Although we regard ourselves as rational, a well-established body of knowledge shows that rationality
plays a less-than-central role in our decision-making process. Confirmation Bias and Myside Bias are
two cognitive biases that influence our decisions.
- Recapping One-on-One Meetings
- Some short one-on-one meetings produce important decisions without third-party witnesses. Instead of
relying on fickle memory to capture these results, send a recap by email immediately afterwards. Recaps
improve decisions and make them more durable.
See also Workplace Politics and Workplace Politics for more related articles.
Forthcoming issues of Point Lookout
- Coming December 11: White Water Rafting as a Metaphor for Group Development
- Tuckman's model of small group development, best known as "Forming-Storming-Norming-Performing," applies better to development of some groups than to others. We can use a metaphor to explore how the model applies to Storming in task-oriented work groups. Available here and by RSS on December 11.
- And on December 18: Subgrouping and Conway's Law
- When task-oriented work groups address complex tasks, they might form subgroups to address subtasks. The structure of the subgroups and the order in which they form depend on the structure of the group's task and the sequencing of the subtasks. Available here and by RSS on December 18.
Coaching services
I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.com or (650) 787-6475, or toll-free in the continental US at (866) 378-5470.
Get the ebook!
Past issues of Point Lookout are available in six ebooks:
- Get 2001-2 in Geese Don't Land on Twigs (PDF, )
- Get 2003-4 in Why Dogs Wag (PDF, )
- Get 2005-6 in Loopy Things We Do (PDF, )
- Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, )
- Get 2009-10 in The Questions Not Asked (PDF, )
- Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, )
Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info
Follow Rick
Recommend this issue to a friend
Send an email message to a friend
rbrenyrWpTxHuyCrjZbUpner@ChacnoFNuSyWlVzCaGfooCanyon.comSend a message to Rick
A Tip A Day feed
Point Lookout weekly feed