Posted
by
timothy
on Monday November 05, 2001 @10:03AM
from the now-stop-abusing-the-mozilla-team dept.

J.P.Lewis writes "
Is programming like manufacturing, or like physics?
We sometimes hear of enormous software projects that are
canceled after running years behind schedule.
On the other hand, there are software engineering methodologies
(inspired by similar methodologies in manufacturing)
that claim (or hint at) objective estimation
of project complexity and development schedules.
With objective schedule estimates, projects should never run late.
Are these failed software projects not using proper
software engineering, or is there a deeper problem?" Read on for one man's well-argued answer, which casts doubt on most software-delivery predictions, and hits on a few of the famous latecomers.

"A recent academic paper
Large Limits to Software Estimation
(ACM Software Engineering Notes, 26, no.4 2001)
shows how software estimation can be interpreted in
algorithmic (Kolmogorov) complexity terms.
An algorithmic complexity variant of mathematical (Godel)
incompleteness can then easily be interpreted as
showing that all claims of purely objective estimation of project
complexity, development time, and programmer productivity are
incorrect. Software development is like physics: there
is no objective way to know how long a program will take to develop."

Writing software is not like building bridges because halfway through the project some dumbass from marketing doesn't come down and tell you that concrete is out and so it needs to be a steel bridge. Oh, and those tacky cables have got to go -- the focus group hated them.

He very carefully laid out the algorithm - I don't have my textbook handy, but it involved elementary mathematical operations on estimated man hours, estimated lines of code, estimated overhead, etc., then at the end -- and I am not making this up -- they multiply the result by a "magic number".

It hit me then that the whole discipline of estimating cost completion is all bullshit. You might as well be estimating with a crystal ball or divining the future with chicken bones. Since I've been working, the best advice I've gotten so far has been "take how long you think it'll take and double it".

Back when I was in middle school my math teacher told me that in order to calculate the area of a circle you had to square the radius and (I am not making this up!) multiply it by a magic number. They even had some hocus-pocus name for the magic number.

It was then that I new the entire field of mathematics had been invented by a bunch of wackos, and that my method was much better. I guess how large I think the area is and then double it. Works for me.

Writing software is not like building bridges because halfway through the project some dumbass from marketing doesn't come down and tell you that concrete is out and so it needs to be a steel bridge. Oh, and those tacky cables have got to go -- the focus group hated them

Oh yeah, and while we are at it, it is no longer a bridge we want, it is a tunnel. And it doesn't cross the river any more, it is going to be used as a large wine cellar. And the 50million dollar budget is now 2 million, the 3 year estimate is now six weeks, we need you to use baseball bats and plastic spoons to dig the damn thing, oh yeah and when will it be ready ?

Let's assume that it is possible to have a fixed deadline, then in order to meet it you will need to get all the specifications for the program, such that they will not be changed while you're developing it. Moreover you need to have a boss that doesn't add functionality to an already started project. All these things are completely impossible, that's why our initial assumption was
incorrect. A very flexible deadline? Maybe...