On 12/1/2013 12:05 PM, Ian Graham wrote:
> Worth having a look at
> http://scribblethink.org/Work/Softestim/kcsest.pdf, which attempts to
> demonstrate:
>
> "Algorithmic (KCS) complexity results can be interpreted as
> indicating some limits to software estimation. While these limits
> are abstract they nevertheless contradict enthusiastic claims
> occasionally made by commercial software estimation advocates.
> Specifically, if it is accepted that algorithmic complexity is an
> appropriate definition of the complexity of a programming project,
> then claims of purely objective estimation of project complexity,
> development time, and programmer productivity are necessarily
> incorrect."
>
> Which effectively means it's impossible to predict cost / timelines for
> sufficiently complex problems, without actually doing the problem. A
> bit of a 'duuh' maybe for those here, but it's still nice to have this
> backed up by a fancy paper with a cool mathematical proof.
Ah yes, the halting problem arises in another guise. Strictly speaking,
since many complex programs cannot be proven to ever complete, how then
could one arrive at an accurate estimate for developing a successful
complex program (at least if it's one of those)?
A lot depends on how similar the project is to others that have already
been developed. Of course, if you start with a new team each time, the
similarities may not be very helpful.
One way to approach the estimation problem is to proceed in phases. At
each phase, you re-estimate based on what you have learned. But that
can be awfully hard to write a contract for, and hard to find managers
that can accept the approach. For the Affordable Health Care system, it
probably would have been impossible to get Congress to fund several
stages flexibly, so if later phase estimates had increased a lot, there
wouldn't have been any way to get money to cover it. Of course, the way
it's worked out, the money has had to be obtained from somewhere anyway.
