Are we anchored to the past?

September 17th, 2010 Nate Tobik, Consultant  (email the author)

“Should we build a new system, or enhance the existing system we already have?”

This is a common question we often face as consultants and developers, as developers our instinct is to always build something new.  A new system will enable us to use newer technologies, and to start fresh without any of the bugs or quirks of the old system.  In addition, building a new system is a lot more fun than maintenance patches for something that already exists.  Usually the inclination of management or the business is to keep and enhance an existing system by adding, especially when the cost and work effort to build a new system are considered.  I’d like to consider this question from a different angle, most discussions center on code complexity and system design, instead I’d like to focus on two issues which I believe are very relevant to this question, anchoring bias, and the idea of sunk costs.

Sunk cost – These are costs that were incurred in the past and will never be recovered.

Anchoring bias – During normal decision making, individuals anchor, or overly rely, on specific information or a specific value and then adjust to that value to account for other elements of the circumstance. Usually once the anchor is set, there is a bias toward that value.
Anchoring bias begins to exhibit itself when a manager or developer focuses on the cost to build the previous system.  They consider the design, the complexity, the man hours of development, and the weeks of testing.  In light of all those things putting in new features seems to be a simple and easy decision, just extend what already exists.  When someone anchors to the existing solution they start to design or plan in their head how the new features can be hooked in, how reuse can happen between objects, and effectively shut out the thought or consideration of alternatives.  Once a person anchors to an idea they place a much higher value on their anchored idea in comparison to alternatives.   Anchoring prevents a person from making a rational objective decision.

So what is the solution to an anchoring bias?  The solution is to recognize that the original cost in both time and money to develop the system is a sunk cost.  When a system is designed and built estimates of cost savings or revenue gains are usually calculated and expected at some point in the future.  The fallacy is when considering a system enhancement taking into account the original costs.   The best approach is to ignore the original costs and consider what is presently needed to complete the required features.  Focusing on sunk costs can easily lead to an anchoring mentality which then results in a less than optimal system.
So what are some actions we can take to avoid anchoring bias when reviewing enhancement requests?  Here are a few steps I believe one can take that will help avoid focusing on sunk costs and an anchoring bias.

  • Evaluate the needs of the enhancement on a standalone basis.
  • Secondly ask the question “How much of the enhancement is common to the existing system verses how much does it differ from the existing system?”
  • Thirdly consider the cost of retrofitting the existing software. Often adding features to existing code has a habit of changing existing features in the process, sometimes in unintended ways.  This can lead to testing costs, verifying that existing functionality and code still function correctly and haven’t been broken in the process of adding new functionality.
  • Evaluate the payback period or net present value (see footnote) of both approaches.  Choose the project with the largest net present value, or shortest payback period.

Footnotes
Sunk cost: http://en.wikipedia.org/wiki/Sunk_costs
Anchoring: http://en.wikipedia.org/wiki/Anchoring
Net Present Value – The value of future cash flows discounted to present using an interest rate that includes a risk free rate as well as a rate for risk.

Entry Filed under: Agile and Development

1 Comment Add your own

  • 1. RCL  |  September 19th, 2010 at 12:44 am

    I believe that there’s more to consider. Not only sunk costs of previous system, but also costs of re-training people, discontinuity of operation and probability that “newer” design will actually be better than older one. It’s easy to suggest revolutionary solution, but evolutionary solutions are usually wiser… We don’t upgrade our cities by knocking down every house and planning the streets anew.

Leave a Comment

Required

Required, hidden


3 + five =

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

© 2010-2012 Summa All Rights Reserved -- Copyright notice by Blog Copyright