Copyright © 2009 Corvus International Inc. All Rights Reserved
“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. (1917 - 1963)
President of the United States
The Myth of "Myth"
What is an
the late philosopher Joseph Campbell, a myth is not "untrue" as we
normally think of untruth--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.
When the human race passed on its knowledge from generation to generation through oral tradition, the messages had to be memorable. A myth contains the truth wrapped inside a story. The "story" part of the myth is like a wrapper that makes the kernel of truth memorable. Usually the story is the most visible part of the myth, but it is not the important part. And the story is not intended to be literally true.
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, just like a weather forecast, any estimate result should always be accompanied by a probability or likelihood of that result occurring. Otherwise the estimate is incomplete.
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.
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 and make promises to the customers based on that technical projection. 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,
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.
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?...
There are ways to "myth-treat" the unmyths.