Can Software Schedules Be Estimated?
"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."
Lewis also provides a link to this "introduction to incompleteness (a fun subject in itself) and other background material for the paper."
There is only two type of software schedules
1) As long as it takes.
2) Take your best estimate , and double it and add 5 or something....
It prefer the as long as it takes. Other wise you end up with something like Windows Me.
Cruise TT
We can get it done by next week! We can do this because we have just #defined a day as having 2000 hours.
Lewis also provides a link to this "introduction to incompleteness" (a fun subject in itself)
I started writing a paper about this topic once, but I never finished it.
-WetDog
...the real reason estimating doesn't work is that there's no way to predict how much time programmers will spend reading Slashdot...
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
I thought most of us worked for the NSA and FBI.
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.
All equations with constants are obviously flawed.
We're all just normal geeks ...
No need to worry about those sirenes ...
It must be for your next door neighbour ...
Just stay where you are ...
There's nothing to worry about ...
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 ?
"They didn't want it right, they wanted it Wednesday."
"If you're not failing every now and again, it's a sign you're not doing anything very innovative." -- Woody Allen
One of my former coworkers had a relatively accurate method of predicting schedules using a Magic 8 Ball. For example:
"Will this project be done in 8 weeks?"
shake "Outlook not good"
"OK, how about 12 weeks?"
shake "Maybe"
"Hmmm. Let's make it 15 to be sure..."
shake "Yes"
"Yep, this project will take 15 weeks."
And it really annoys managers when they discover that you used a Magic 8 Ball, and then it confounds them when it is right...
"You tell me the month, I'll tell you the year"
sulli
RTFJ.
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...