Can Software Schedules Be Estimated?

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."

Lewis also provides a link to this "introduction to incompleteness (a fun subject in itself) and other background material for the paper."

Software Schedules

[JohnHegarty]

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.

Re:Double the number, add one and raise the unit!

[dattaway]

We can get it done by next week! We can do this because we have just #defined a day as having 2000 hours.

Incompleteness

[wetdogjp]

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

Actually....

[Anonymous Coward]

...the real reason estimating doesn't work is that there's no way to predict how much time programmers will spend reading Slashdot...

Re:Of course they can be estimated.

[[e-mail]]

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.

Re:Software Schedules

[flegged]

Software design is ultimate application of Hofstader's Law, which states:

Everything takes longer than you expect, even when you take into account Hofstader's Law.

Re:Incompleteness

[Anonymous Coward]

I've been meaning to write a SegFault article about the Art of Procrastination, but I keep putting it off...

Re:Incompleteness

[Black Parrot]

> started writing a paper about this topic once, but I never finished it.

Me t

Re:Slashdot readers are students?

[dattaway]

I thought most of us worked for the NSA and FBI.

Re:It's all a bunch of bull..

[ogren]

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.

Where did you hear such a thing?

[Aceticon]

It's totally untrue!!!

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 ...

Re:Of course they can be estimated.

[Anton Anatopopov]

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 ?

From the desk of BOFH

[Anonymous Coward]

Here's how a BOFH handles estimates:

• It'll take as long as it takes -- and it'll take longer if you don't shut up and let me do my fucking job!
• What?! You want me to predict the future too?! Hire a sorcerer and ask him how long this'll take!
• It would have been done already if you kept your mouth shut!

A good quote...

[C_Mattie]

"They didn't want it right, they wanted it Wednesday."

Magic 8 Ball Estimations

[staplin]

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...

Re:Software Schedules

[rodgerd]

Most successful large projects are in COBOL, assembler, or REXX. Especially COBOL.

Standard estimate

[sulli]

"You tell me the month, I'll tell you the year"

Deadline estimate

[$criptah]

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...