“The great enemy of the truth is very often not the lie -
deliberate, contrived and dishonest - but the myth -
persistent, persuasive and unrealistic” 
        John F. Kennedy Jr.

 

    The Myth of "Myth"

What is an "unmyth"? 
 

According to the late philosopher Joseph Campbell, a myth is not "untrue" as we normally think of it--it is not a falsehood or a lie.
In fact, according to Campbell, a myth is actually the essence of truth, but it is wrapped up in a fairy tale that makes it memorable.

Myths were created by humans when we had to pass important truths through oral tradition--the stories had to be memorable.  The "story" part of the myth is like a wrapper that makes the kernel of truth memorable.

So, if a myth is a truth that appears false, then an unmyth is a falsehood that appears true.  There are ten unmyths in software project estimation:

• The Accuracy Unmyth: You can (somehow) create an "accurate" estimate
  An estimate is an estimate--it is imprecise simply by definition.  In fact, any estimate result should always be accompanied by a probability or likelihood of that result occurring.  Otherwise it's bogus.
   

• The End-Date Unmyth: The purpose of an estimate is to determine when a project will finish
  Depending on how we run a project, and what probability we want of success, we could predict almost any end date.  Ditto cost, staff, quality, and scope.
   

• The Commitment Unmyth: An estimate and a commitment (to an estimate) are the same thing
  An estimate is a technical projection of what might happen, a commitment is a decision to allocate resources.  An estimate operates on technical data about how effective an organization is at building software, a commitment operates on business data on what the return on investment (at an acceptable level of risk) might be.
   

• The Size Unmyth: An estimate is dependent on the size of the final system being delivered
  Despite the fact that pretty much every estimation process uses delivered system size as its key driver, if we have a lot of reuse or experienced people or a very simple system, we might be able to build a system very quickly.  On the other hand, if the customer keeps changing his mind or the technology we use is flawed or we have high turnover on the project, it might take a really long time.  While delivered size is one of the more important inputs to an estimation process it can, under certain circumstances, be complete swamped by the effect of other factors.  The key factor is not the system size--it is how much knowledge has to be acquired.
   

• The History Unmyth: Historical data is an accurate indicator of productivity
  Financial investment prospectuses usually say: "Historical performance is not an indicator of future performance..." , and so it is with projects.  The problem is that the difference between the last project and this project (which is where the history doesn't track well) is the very reason why this project exists,
   

• The Productivity Unmyth: Productivity is an accurate predictor of project duration
  See the Size Unmyth, it's about the same.
   

• The LOC Unmyth: A Line of Code (LOC) count is a good way to size a system
  How would we know how many LOC we will create when we are in early project development?  The real problem is we want to count knowledge and knowledge is intrinsically uncountable: there is not empirical way to measure it, there is no unit for knowledge, and besides we really need to count the knowledge we don't have.
   

• The Function Point Unmyth: If LOC are not a good way to size a system then Function Points are a good way
  While useful, Function Points don't explicitly count system attributes such as state behavior, complex algorithmic functions, platform dependence, and a host of other things.  So if your system has these attributes, a FP count may not track to the actual knowledge-to-be-gained.  Plus it can be a lot of work to calculate the FP, even if we have a good specification.
   

• The More People Unmyth: We can get the system faster by assigning more people
  The relationship of effort/staff headcount to schedule is not linear (it's actually a high order reciprocal exponent) so simply adding people doesn't necessarily have a pro rata effect on schedule.  Adding nine women to a project that is late won't necessarily get you to the church on time.
   

• The Defect-free Unmyth: Given enough time (process, inspections, testing, skills,...) we can create a defect-free system
  We can only determine if something is defect free by comparing it against some set of expectations (this comes from The Dual Hypotheses of Knowledge Discovery--See "The Laws of Software Process" for more details).  But how do we know the set of expectations is defect-free?  Well, we would have to measure it against the expectations of expectations.  But how do we know the expectations of expectations are defect free?...
   

    The good news is that there are ways to "myth-treat" the unmyths.

 

Ten Unmyths of Project Estimation