Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Are There Limits to Software Estimation?

timothy posted more than 12 years ago | from the semantics-and-realities dept.

Programming 225

Charles Connell submitted this analysis on software estimation, a topic which keeps coming up because it affects so many many programmers. Read this post about J.P. Lewis's earlier piece as well, if you'd like more background information.

cancel ×

225 comments

Sorry! There are no comments related to the filter you selected.

Hello p0rn_k1ng! (-1)

cyborg_monkey (150790) | more than 12 years ago | (#2823473)

I am your master!

Re:Hello p0rn_k1ng! (-1)

TrollMan 5000 (454685) | more than 12 years ago | (#2823527)

Don't you mean "Pr0m Qu33n"?

How'z it hangin' d00d? Nice fp there. Mad pr0pz!

Re:Hello p0rn_k1ng! (-1)

Fucky the troll (528068) | more than 12 years ago | (#2823666)

ah, TM3K. My favourite shit-demon. How are you? How're things on your side of the bed? I noticed you cleaned off all those bloodstains after the hamster massacre. Nice one! What was the count in the end? 50? 60? The little bastards deserved it anyway. I'll always remember those squeals :)

Ah!! (-1)

j0nkatz (315168) | more than 12 years ago | (#2823605)

Hey bro! Know what this is??

Another story.....
for me to p00p on!

Re:Hello p0rn_k1ng! (-1)

Tasty Beef Jerky (543576) | more than 12 years ago | (#2823671)

This is indeed momentous. Congratulations on your First Post Mr. Monkey. It has been a long time since I've seen an FP by CM, and a followup by TM5k. You two had the most influence on me during my early crapflooding career. And while part of me is moving on to bigger, more interesting things, a piece of me will always remain a nasty crap-flooder (As demonstrated by my crapflooding accounts).

Mad propz gentlemen, and my best wishes for many more first posts to come.

Oh, and Pink Floyd rules. Anyone that disagrees can get me caught between their teeth and have a hard time getting me out.

Re:Hello p0rn_k1ng! (-1)

cyborg_monkey (150790) | more than 12 years ago | (#2823741)

Thank you for your kind words. I have not bothered too much lately.. but I managed to grab one yesterday.

be sure the visit scoop.geekizoid.com!

Re:Hello p0rn_k1ng! (-1)

Tasty Beef Jerky (543576) | more than 12 years ago | (#2823782)

I attempted to set up an account on slash.geekizoid.com, but I never got the e-mail informing me of my password. I even tried having it sent several times, but it never came to me. I was rather disappointed.

first toast (-1)

Anonymous Coward | more than 12 years ago | (#2823485)

with *real* butter

Friday night! Gimme some porn people! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823820)

I want it.

I know you want it.

We all know the Slashdot crew just lives for it!

Please post links to hot gay porn. In particular, I'd like to see hot shots of penis-2-penis (P2P) action with hot white man-juice spread all over beautiful, muscular ebony skin.

I am the page lengthener!!! (-1)

CmderTaco (533794) | more than 12 years ago | (#2823491)

3 [goatse.cx]
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
63
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6

Of course there are limits. (3)

laserjet (170008) | more than 12 years ago | (#2823498)

We all know that software schedules, etc. can be estimated, but not with a large degree of accuracy. It has always and will always just be a case of risk management, and whether you want to release early to market, or release late and have a better product.

In the real world, we don't go by some estimation or rigid schedule, and we wouldn't have to if not for the accountants and marketing people that have to prove their usefulness. THEY are the people who want estimates, and incredibly, they are also the people who have the least idea as to what is requred.

Re:Of course there are limits. (3, Insightful)

mccalli (323026) | more than 12 years ago | (#2823594)

In the real world, we don't go by some estimation or rigid schedule, and we wouldn't have to if not for the accountants and marketing people that have to prove their usefulness. THEY are the people who want estimates, and incredibly, they are also the people who have the least idea as to what is requred.

Not always the case. You're thinking about, essentially, a 'shrinkwrap' environment. Early/late to market and all that kind of stuff. However, a large amount of code is written in-house for in-house use only. Not software houses, but places like banks, government...basically any large institution with a fair few IT systems.

Your users there aren't developers, and many are more used to work which follows predictable patterns. That's not to say their work isn't hard or even non-technical, it's just that the nature of many tasks tends to be more predictable than that of writing code.

Most code is utter drudgery. It's predictable in an informal manner to a very high degree. These users get used to that. If you then predict three days on something, hit an actual problem and take three weeks - they will hold you to account. Your explanation at that time had better be good.

Cheers,
Ian

Not your father's goatse (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823610)

goatse.cx -- genesis! [google.com] !

Re:Of course there are limits. (2)

pubjames (468013) | more than 12 years ago | (#2823687)

In the real world, we don't go by some estimation or rigid schedule, and we wouldn't have to if not for the accountants and marketing people that have to prove their usefulness.

In the real world, companies have to be profitable and keep clients happy by delivering projects on time.

Unless it's a simple project... (5, Interesting)

Nijika (525558) | more than 12 years ago | (#2823502)

There are always things you won't consider until something's being developed. If you've done something a thousand times, and have the libraries developed then you can probably estimate the time required very accurately. If the request is something completely new to your team, you'll never be able to accurately estimate the time required until analisys (which takes it's own time as well).

Re:Unless it's a simple project... (3, Informative)

squaretorus (459130) | more than 12 years ago | (#2823553)

A technique I think would work well for medium sized projects is build and burn.

You build the project once through, cobbling things together to get as close to what you want in a given time frame. You then start again from scratch.

Version two of any software is always better, so get straigh on with it. Involve the user towards the end of the initial build.

You then spend time assessing how you would do it properly, hopefully having had a majority of 'niggles' highlighted during the initial sloppy build.

I often do this for smaller projects, but think it could scale pretty well. If you spend 20% of the total build time on the initial build - but that lets you estimate the total time more accurately, there are great business benefits to be had.

Re:Unless it's a simple project... (2, Insightful)

jeremyp (130771) | more than 12 years ago | (#2823731)

If you want to build an application that the user wants/needs and will use, you need to involve them towards the beginning not the end. The cost of fixing a mistake (in terms of man-time) is dependent on when the mistake is made and when it is discovered i.e. if a mistake is made during requirements definition e.g. a feature left out, it is much cheaper if the problem is found out during review of requirements definition than if it is discovered during the final acceptance testing. Steve McConnell recommends building a user interface prototype which you get approved by the actual users and which then becomes part of the requirements definition.

Fred Brookes said "plan to throw one away." Meaning your first attempt at solving the problem may turn out to be a crock of s**t. Somebody else said "if you plan to throw one away, you'll end up throwing two away."

Re:Unless it's a simple project... (2, Insightful)

thenerd (3254) | more than 12 years ago | (#2823739)

You then spend time assessing how you would do it properly, hopefully having had a majority of 'niggles' highlighted during the initial sloppy build.

I read once about a phenomena a lot of people have observed, namely 'second system syndrome'. This is where the second system would be over-engineered and excessively grand, due to all the problems that had been encountered in the first version. 'We've done the first version, we can handle this, so let's make a proper one now'.

I have seen this - it would point to the third version being about right =).

thenerd.

Re:Unless it's a simple project... (2, Funny)

batboy78 (255178) | more than 12 years ago | (#2823796)

Thats not the way CMM works, with a structured process you get things right the first time. I admit it is a huge pain in the butt. But it certainly increased our productivity, and scheduled releases. I beleive that there are only 2 Level 5 organizations in the US, NASA, and the ALC(Air Logistics Center?, at Ogden). And at level 5 they don't even need a testing organization to release mission critical applications.

Re:Unless it's a simple project... (1)

mike_the_kid (58164) | more than 12 years ago | (#2823826)

This only works if your goals for version two are a stable version one. The prototyping to reimplement makes sense if you have enough time. And sometimes you do.

The underlying point that comes up is that the code is not as valuable as the experience of writing it. This is why a modular framework is so good to have, so you can take small bites but see real effects. You realize the rewards more quickly. On top of that, modular code is less "write-only".

The rub is, of course, that you might spend as much time writing a modular, robust system as you would writing the same system from scratch twice, as is suggested in the parent comment.

Too much thought on one thing... (4, Insightful)

FortKnox (169099) | more than 12 years ago | (#2823506)

There is only one way to make a good estimate on a software project:

Experience

It looks to me like someone just had too much time on their hands, and decided to say that in a very, very complex manner.

Sheesh.

Re:Too much thought on one thing... (1)

Lozzer (141543) | more than 12 years ago | (#2823545)

I thought he gave himself away at the end.

"Good people who know what they are doing are invaluable to the software process"

Well, no shit sherlock as they say over here.

Estimation time for projects (1, Funny)

TrollMan 5000 (454685) | more than 12 years ago | (#2823513)

Can be best based on these [sunspotcycle.com] .

It's all about people (2, Insightful)

spatrick_123 (459796) | more than 12 years ago | (#2823529)

Metrics and processes worry me to some extent on this particular topic, because often times it seems that managers think that anyone can apply a few algorithms to a set of data and come up with an estimate.

What's truly important is that intuitive feel that people develop over time for what the bottlenecks will be, how their particular organization operates, etc, etc...

You can teach number-crunching, but you can't develop that intuition without experience.

Alistair Cockburn on People as the biggest Factor (3, Informative)

uqbar (102695) | more than 12 years ago | (#2823733)

Alistair Cockburn [aol.com] has a number of excellent papers on this point:

The net-net is that human factors are far more important - and it's really hard to plug these into an estimate. One of Cockburn's contentions is that people aren't linear or predictable. But he also identifies items that can help a project run more efficiently. An excellent read at any rate.

An book worth to read (4, Insightful)

frankie_guasch (164676) | more than 12 years ago | (#2823535)

Rapid Development : Taming Wild Software Schedules
by Steve C McConnell

Take a look back (2, Informative)

BaltoAaron (242546) | more than 12 years ago | (#2823536)

This has been posted before here. [slashdot.org]

Re:Take a look back (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2823653)

And I've fucked your mother before. But I don't go bringing that up each time I fuck her.

Re:Take a look back (0)

Anonymous Coward | more than 12 years ago | (#2823667)

You didn't click on the two links in the post, did you?

Neither did the moderator...

many factors in estimate (0, Funny)

neal n bob (531011) | more than 12 years ago | (#2823543)

the number of anime festivals during the development time, what new PS2 games are soon to be released, whether there is a Magic: the gathering convention - all of these things affect the time needed for those smelly geeks in software dev to get off their butts and get the job done.

2x+7 (5, Interesting)

Lizard_King (149713) | more than 12 years ago | (#2823544)

In a software engineering class in college, I remember a professor joking around that the catch-all equation for software estimation is 2x+7, where x (can be in any units like hours, days, weeks, minutes) is your estimate for how long you think the component will take. So for example, If one of your developers estimates that developing some component will take 4 hours (so x = 4), in *reality* it will take them 2x+7 = 15 hours to complete.

After gaining a few years of "real world" experience in software engineering (and I know that the very term real world experience is debatable :-), I'm realizing that this professor wasn't that crazy, and his crude estimation mechanism (which is a joke) isn't any more or any less accurate than a lot of modern techniques I have seen people use in the field.

Re:2x+7 and Duke Nukem Forever (1)

kormoc (122955) | more than 12 years ago | (#2823601)

Hey all, we estimate it will take 2 years to write

so plug it in
2(2)+7=11 Years, Wow, vapor until 2010!

Re:2x+7 (2)

superid (46543) | more than 12 years ago | (#2823668)

I double the initial estimate and go to the next higher unit.

When you factor in specification meetings, design reviews, actual coding, testing, and finally release (lather, rinse, repeast) it can be remarkably close.


SuperID

Re:2x+7 (0)

MrChris007 (523454) | more than 12 years ago | (#2823729)

I have head (2X)^2 ... this is the "Estimation" I use. I have been programming for a long time and I hate it when a client comes to me and immediately wants a cost / time estimate before they have even given me any real details of the project. In these cases I take my estimate (x) and double that and then square it.

Re:2x+7 (1)

hogsback (548721) | more than 12 years ago | (#2823805)

(can be in any units like hours, days, weeks, minutes)

It won't give the same answer though

I estimate 1 year : you calculate 9 years
I estimate 365 days : you calculate 737 days (2 years)

Estimating software development cost (2, Insightful)

pieterh (196118) | more than 12 years ago | (#2823546)

Getting a price tag for software development is like knowing how much you're going to pay to build for a new house. Software is incredibly expensive to build. Any professional needs to be able to say: it will take so and so long and that means such and such a price tag.

The risk and uncertainty stem IMHO from two factors: the importance and rarity of talent and skill (a really good programmer can work ten times faster and produce a finer result than a 'normal' programmer); secondly, the inventive nature of much software development. When you make something new it's impossible to know what surprises you will get.

The more one works with standard pieces and the less one depends on extremes of talent and skill, the more predictable software development is.

Re:Estimating software development cost (1)

zoombat (513570) | more than 12 years ago | (#2823787)

Getting a price tag for software development is like knowing how much you're going to pay to build for a new house. Software is incredibly expensive to build. Any professional needs to be able to say: it will take so and so long and that means such and such a price tag.

That works OK for a house.. or moderate sized programming tasks.. but when the scale grows to say a major version upgrade on a complex operating system, the numbers get a little more difficult to calculate. I live in Massachusetts: Good old Boston's got the "Big Dig" screwing up all the building cost estimates and eating up cash faster than you can imagine.

It's great to develop calculating tools - especially because it will help you figure out when people are wasting time or embezzeling money or something... but just because you have a good estimating formula, doesn't necessarily mean the project will finish within bounds.

QA (1)

MoceanWorker (232487) | more than 12 years ago | (#2823551)

my last company i worked for... we developed a proprietary program for internal use only to catalogue what we had in a "nice, friendly" environment (it was a procurement company).. of course the code would never fully be completed, but it was a very long and tedious procedure due to QA... in my opinion, i usually think QA has probably one of the biggest roles with development.. without them we'd be releasing buggy programs left and right

Re:QA (1)

batboy78 (255178) | more than 12 years ago | (#2823830)

The thing about QA is that they have to be knowledgeable about what they are going over, when QA would do a code review, I could put anything in the code I wanted and they wouldn't have a clue "PRINT "QA are a bunch of goons". It was embarassing how lacking these guys were.

Re:Estimating for QA (1)

jayfang (523418) | more than 12 years ago | (#2823854)

have I been trolled? 8-0 "you can't test your way to quality" - Larry L. Constantine

The time spent in testing is inversely proportional to the quality of the software which tends to be proportional to the time allowed for development.
ie. The worse (more rushed, etc) the SW project then the longer the QA cycles.

You're not alone, there are plenty of pointy headed bosses out there that don't get it.
Note that QA should be distinguished from develop/test/use iterations.

Jayfang
cycling sig- So what is in your waterbottle comrade?

Accuracy, and doubling a double (5, Interesting)

CDWert (450988) | more than 12 years ago | (#2823554)

I have been in this industry for what often times seems too long, My father was in from the beggining 1962, When I was younger and he asked me how long I thought it would take to write I blurted out my answer and he said no X , I said noooo thats way too long how did you arrive at that ?

Here was his answer I have ALWAYS found it accuraye to +/- 10% so far on hundreds on small to massive projects.

1. Once you know all , or most of the forseeable estimates take that number. say 10 hours.

This number is an instinctual reaction to a perfect enviroment , a little experience, some ego on your part of what might be accomplishable in a vacum.

2 Take that Number ad double it.
This takes into account all the real world distractions. Events, etc.

3.Take that number and double it again. This takes into account unssen variables and events beond mortal control.

40 Hours.........

I use this on EVERY single estimate I provide, WHY ?? It works, its not too high not too low, just right.

I tell people this and they laugh, then I tell them that there are MANY legacy applications SSI, IRS, FBI, you name it that were qutoed by my father in this EXACT manner.

There is NO practical limit to estimation, As long as you have the information neccesary to determine what the job youre actually doing is.

Re:Accuracy, and doubling a double (4, Informative)

jpbelang (79439) | more than 12 years ago | (#2823692)

The danger with constantly doubling is that it leads to falsely large numbers for small projects.
A project estimated at one day should NEVER take four days. A project estimated at three months could take a year.

In my opinion, everything is about risk and you seem to agree (the reasons you double your time is generally for unforseen events).

So if risk is the problem, we have to reduce risk. How should this be done ? The simple solution is shortening your horizon.

Instead of saying "this project of size X will be delivered in three months", deliver smaller increments more often ("this project of size X/12 will be delivered in one week")

This is extreme planning.

So I'm an XP evangelist. sue me :)

Re:Accuracy, and doubling a double (5, Insightful)

pubjames (468013) | more than 12 years ago | (#2823717)

I use this on EVERY single estimate I provide, WHY ?? It works, its not too high not too low, just right.

A task will expand to fill the time available... That's why your method of estimation always seems just right.

Re:Accuracy, and doubling a double (1)

zoombat (513570) | more than 12 years ago | (#2823719)

I prefer the addage: times 2 plus 1

where you take a programmer's estimate and double it
then incriment the label by one unit

so if you think it will take 2 hours,
it will really take 4 days.

or if you think it will take 4 days,
it will really take 8 weeks.

If you think it will take 1 month,
it will really take 2 years.

Programmers almost always seem to be overly optimistic, poor time managers, procrastinators, or over confident in their own abilities.

Of course it gets more complicated when you have more than one person programming. For every person on the project beyond 1, add 10% total time.

(If you really use these figures you're a moron.)

Gut level formula (1, Interesting)

Anonymous Coward | more than 12 years ago | (#2823558)

Look at the initial proposal for at least a few days if it's major.
Take your gut feeling about the development time required.
Multiply that by 20.
Divide the result by the number of years you've been developing similar projects.

it develops over time (3, Interesting)

foo(foo(foo(bar))) (263786) | more than 12 years ago | (#2823563)

I work on a very large software project. 6million+ lines of active source code, with 400,000 new development hours per year and growing. -and- we are on our extimates well over 80% of the time. (if we don't hit it, we are under).

How is this possible? It has evolved over time, some of the same people who started this project 9 years ago are still here and they know the system very well. That knowledge, combined with good project management leads us to several categories. During a requirements phase, designers assign a complexity to the changes for a module, and based on the type an hours extimate is generated.

Now, Lewis is right, no algorithm can be developed to figure out the compleixty, but a human can, and the computer can figure out how many hours should be devoted to documentation, coding, and testing.

My overall point, as a software product matures...esitmates are easy to estimate and project dates are easier to meet. But you already knew that...

Re:it develops over time (0)

neal n bob (531011) | more than 12 years ago | (#2823623)

lets see - 400,000 new dev hours and growing; 6 million lines, started 9 years ago. I got it! You work for the goverment and this 9 year old legacy piece of crap you work on probably doesn't do jack crap!!!!

Re:it develops over time (1)

Peyna (14792) | more than 12 years ago | (#2823675)

I suppose his conclusion is along the same lines as that there is no algorithm that can determine whether another given algorithm is absolutely correct for any given input.

Basically, you try your best to make it perfect, but you can never be 100% certain.

Who is the article for? (2, Interesting)

f00zbll (526151) | more than 12 years ago | (#2823568)

I haven't read the article (I plan to), but from the post, I get the impression it is more for Project Manager and Exec types. Experienced developers know first hand how hard it is to estimate development time.

What I would like to know is, how is this going to effect expectations from non-technical people in charge of projects that demand "accurate" estimates. I've had good and bad managers, maybe these kinds of articles will help make developers life a little less stressful and more flexible.

†† (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823569)

Programmers intuitively know this (5, Interesting)

Anonymous Coward | more than 12 years ago | (#2823572)

Programmers that I've worked with have almost always intuitively known this to be true, and non-programmers (in particular, product managers responsible for scheduling) have almost never understood this. Hence the frusteration on both sides.

I'm glad there's finally a resource to help the folks who insist on accurate estimates understand why my response to the inevitable inane question is always a cynical "two weeks", regardless of the complexity of the problem.

Two-week estimates (1)

Anomalous Cowbird (539168) | more than 12 years ago | (#2823797)

And the response later is, "Oh! You thought I meant two calendar weeks? I meant two CPU weeks!"

Problems with scheduling (3, Insightful)

(trb001) (224998) | more than 12 years ago | (#2823583)

A problem that seems to come up in scheduling and time estimation is that the people producing the estimates aren't the people doing the actual work. Add onto that the customer giving additional requirements, changing requirements mid project, putting together a team that doesnt have the skills necessary to produce on time deliverables, etc...that's a LOT of variables.

I don't want to sound like that programmer who makes excuses for why their project isn't delivered on time ("That other guy was a moron", "Management is horrible", "We didn't have solid requirements") but IMHO, if you want a program delivered on time, pick a good team and then try to estimate the amount of time it will take...then reduce that by 20%. It seems like every project is late by about 25% or more, so if you reduce it initially, perhaps it will be delivered closer to when you really expected it.

--trb

Re:Problems with scheduling (1)

jeremyp (130771) | more than 12 years ago | (#2823778)

Most projects are late by much more than 25%. Somebody did a study on some big defense projects and came up with a figure closer to 135% or possibly even more.

Re:Problems with scheduling (2)

Gleef (86) | more than 12 years ago | (#2823788)

trb001 writes:

A problem that seems to come up in scheduling and time estimation is that the people producing the estimates aren't the people doing the actual work.

A good project manager will make sure to ask developers for their own estimates and make use of that information.

Add onto that the customer giving additional requirements, changing requirements mid project,

If you are estimating from a documented specification, then these changing requirements can be estimated and documented. "It will take us six months to complete this specification, if you want to add this feature it will add two months to the schedule, just how important is this feature again?"

putting together a team that doesnt have the skills necessary to produce on time deliverables

Good people are hard to find, but the project manager can be reasonably expected to know who is working on the project and how competant they are, and plan accordingly.

...estimate the amount of time it will take...then reduce that by 20%.

Are you kidding?!? Don't reduce the time estimate, even if everything goes perfectly, the chances of you getting everyone to do what they said in 80% of the time is almost zero. Generally, depending on the complexity of the project, I take my best estimate of how long it would take in a perfect world and increase it by 100-200%. People call in sick, unexpected complications arise, there's all sorts of things that will increase the schedule, and those are the hard to predict parts of estimation.

Human timing (0)

ShecoDu (447850) | more than 12 years ago | (#2823586)

It is certainly hard to produce an estimate since the bigger the project gets and the longer the same is beeing developed, the wider the possibilities there are that a new ideas or improvements to project, It is not uncommon to be reaching a deadline and saying, damn it would be nice if I wrote this new module.

Accurate estimates are somewhat irreal, its just a matter of human timing, it doesnt really has to be perfect. Yeah, you can create the shortest project, but who wants small (possibly untested) software?

How many angels can... (2, Interesting)

PHAEDRU5 (213667) | more than 12 years ago | (#2823597)

This reminds me of a paper I came across on the limits of formal methods (http://www.kneuper.de/a-limits.htm).

You can prove philosophically the limits of mathematical methods,. but that doesn't make them useless. A formally-proved system, when put in contact with an informal world, may show itself to have limits, but it'll probably perform better than a system that's not been formally proven, and if it does fail, the reason for the failure will be glaringly obvious.

We build systems of ever-increasing complexity with tools that are constantly playing catchup. Does that mean we ignore the tools? I don't think so. Instead, we reflect and improve.

:-( (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823603)

His name was Cosmic Charlie, and he was doomed to die.

The sentence had been self-imposed, actually, so the fact, cold and open as it was, was not nearly as dramatic as it might seem. But the impending death was real, imminent, and threateningly certain, just as sure as the bulbous-red nose on Charlie's face.

"Taxes," Charlie used to say on the telephone to strangers, old friends, new enemies, anybody who'd listen. "The only certain thing in life? Hmmph?!"

"Who is this?" Mrs. Gretchen Houynhym of the 213 area code said uninterestedly into her end of the receiver. Of course, she knew who it was. But she wasn't doing anything in particular at the moment, nor was she particularly frightened by Cosmic Charlie's ravings. It was his time, after all, and their time. Somewhere, in the back of her mind, she wondered if Cosmic Charlie was masturbating into the phone, somehow stimulated by her confused pleadings for information.

She didn't mind supplying Charlie with whatever cheap excitement he desired; for she had worked her way through a year of junior college as a 976 phone sex girl (before she got married, of course, at least that's what her husband thought -- yet she had gone back to working the phones three times, for four hours each time, when money was tight after the baby came).

"Death!" Cosmic Charlie said into the telephone. Death was, after all, his favorite topic, the central pillar around which the worn, gnarled vines of his life relentlessly constricted. He loved talking about it, loved flirting with it (although he hated pain, to be sure), and would coyly hint around it, sometimes for hours, in his random telephone conversations with bored housewives. If they listened, of course. Only if they listened.

If the women hung up on him, well, they were doomed to die for their impudence. They would certainly be out of his life forever, for Cosmic Charlie took a special delight in crossing telephone numbers out of the great White Pages of his mind whenever they didn't listen to him the way he wanted them to.

Mrs. Gretchen Houynhym narrowed her eyebrows and held the phone closer to her ear, trying hard not to become embroiled in what she knew to be Charlie's deep, penetrating insanity. The sudden impact of a topic not usually on Charlie's agenda was startling her, yet she enjoyed it in a warm-painful sort of fireplace way.

She suddenly wished that he'd get off, go limp, and shut up so she could hang up and go back to her laundry. But another part of her wished he'd go on for hours (not necessarily because that would indicate superhuman virility, but because there was a hypnotic, extra-worldly quality to his voice that made her think, and made her horny, at the same time. She didn't know why).

"What about it?" she said, snapping her gum into the phone and wriggling around in the heat of the kitchen green vinyl chair she'd been sitting in for far, far too long.

Cosmic Charlie, not masturbating, barely able to move, in fact, gasped loudly into the phone. Gretchen, in all her years as a professional, was unable to recognize the gasp as anything other than a moan of rapt ecstasy.

"Are you all right, mister?" she asked.

"Yesssss," Cosmic Charlie said. He wasn't, of course, by most conventional, human, living standards, but he was doing quite well by his own standards. He was nearing death, and he would take a few with him when he went. This much was certain.

Gretchen felt daring -- perhaps it was the Drano fumes she'd inhaled earlier today, perhaps it was her husband's impotence since the baby was born and he'd lost his job at the Ford dealership and had to take a job as an apprentice carpet installer. Or maybe it was all of those things. But she felt daring, so dared she did.

"Do you need some help?" she asked. "I mean, I don't know your name or anything, but...you have been calling here for quite some time now, a few months at least, and I suppose we sorta communicate on the same level. And...well, heck, you sound like you could use a woman around right now."

"Nooooo," Cosmic Charlie hissed. "Death is coming. It's all I neeeeeed."

She left the phone off the hook and went to the other line upstairs -- the boarders' line, installed primarily because they'd planned to rent out their upstairs storage room when they couldn't make mortgage payments. But so far there had been no takers, and Gretchen had just been cleaning and dusting and paying phone bills on the room for no good purpose.

She picked up the phone and dialed 911. She had been a 911 operator in the old days before she'd been married as well. What a hell that was. Always dealing with the sick, macho fantasies of repressed policemen who'd never let her beat them or bite them or rip bloody pieces of skin off their backs when they were making love in parked patrol cars at three-thirty in the morning. What a bunch of backward hicks.

She'd been forced to leave the 911 job, after only six months, after leaving marks on a Sargeant's neck. She went from there to the phone sex job. She remembered it well.

Within a few minutes she'd gotten Cosmic Charlie's address from 911 and was grabbing her purse and coat together. Then at the last minute, just before leaving the house, she eschewed her coat, hurling it to the floor. She didn't know why. Maybe she thought it would make her look more free 'n' easy. Who knows.

She did bring condoms, though. No sense in killing herself over a passing fancy.

Cosmic Charlie's house was not in the 213 area code. It was in the adjacent 818 area code. So there was a bit of driving involved for Gretchen. She didn't mind. When there is excitement, delicious unknown excitement at the other end of an auto trip, no distance is too long to travel.

There was sweaty-loud male moaning coming from behind the door as she climbed the steps.

"Mister?" she called, knocking lightly on the wooden-framed screen door. "Are you all right?"

"Yeeeeeees," said Cosmic Charlie.

"Is there...is anybody else in there with you?" She felt terrible about asking, but she felt she had to be prepared.

"Yeeeess," Cosmic Charlie of the 818 area code cried. He let out another howling moan.

Gretchen's eyes widened. She wondered who else could be in there, making him make those noises. Was it another woman? Or more than one? Or a man, even? Or an animal or a machine or a imaginary friend who instead of fading away at puberty when real friends came to take its place only grew larger, and lovelier, and more real, until you could almost touch it, and it could _certainly_ touch you, and it _did_ touch you, at every opportunity, until your thighs chafed with juicy desire whenever it entered the room?

No. It could be none of those things. Call it feminine intuition, but she knew in her experienced heart that the scene inside the home of Cosmic Charlie was nothing like what she expected.

Uninvited, she threw open the door.

"Come in," he said. He was lying in on a couch, in the living room, amidst a forest of realistic statues of women. The statues were not quite love dolls, but they were far too realistic and naked-shiny to be considered department store dummies either.

Gretchen did not want to enter the home of Cosmic Charlie, but felt she should for his own good.

"Come a little closer. A little more. There! Stop. Stop right there."

From her vantage point in the musty-still darkness, Gretchen could see that Cosmic Charlie was probably not the wild-eyed fiend she'd hoped he would be. There was nothing of the satyric gleam she'd come to know well in -- well, in other trades she'd practiced over the years. Instead, Cosmic Charlie's eyes were jaundiced, dying, and limp. She would not use condoms here, today. She'd be lucky to get a decent conversation from this sap.

"Death," he began. "Death stops everything. And out of death, we may find life."

Gretchen didn't like what she was hearing. It was beginning to sound like the Catholic funeral they'd had for her three-year-old niece last winter.

"But I have found a way to capture both life and death," Cosmic Charlie stated.

"How's that?" Gretchen said with a smirk, hoping that his method involved some form of below-the-belt Swedish massage.

"Stay right where you are," Cosmic Charlie said, reaching his bony, decaying hand across the couch to a golden cord tied by a sash to a specially-placed knob on the wall. "And...LIVE!"

At the pull of the golden cord, a huge bucket full of some kind of quick-drying acrylic substance cascaded down upon her body from above. It reacted with her clothing, burning it, then hardening on her skin. Within seconds, her clothes were in tatters and she was unable to move, within a minute she could not breath and stood there, rooted to the spot, to join the other bored housewives of the 213, 818, 714 and 805 area codes in eternal life and never-ending lifelessness.

"Better living through chemistry," Cosmic Charlie said.

"Mphhggglllph," said Mrs. Gretchen Houynhym, formerly of the 213 area code.

"That's right. Better living through chemistry." Cosmic Charlie expectorated his next-to-last dying gasp in the general direction of his impressive mannequin collection, and wondered who would receive the glorious blessing of death first: himself or Mrs. Gretchen Houynhym, formerly of the 213 area code.

why did they do it? (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823613)

I still do not understand why the only blew up half the Death Star?

You must trust my judgement-Qui Gon Jin

This has to be.. (-1)

Fucky the troll (528068) | more than 12 years ago | (#2823616)

the most pointless piece of shit ever unleashed onto the slashdot community.. I mean, COME ON!

"In addition to relying on human skills, we also should continue to pursue formal methods of software estimation, which hopefully will provide reasonably accurate time estimates for most development tasks.

Booooollllooooccckkksssss!!!

Re:This has to be.. (-1)

Tasty Beef Jerky (543576) | more than 12 years ago | (#2823773)

Need to borrow a shovel? It seems to be stacked pretty high in here...

Real World (0)

Anonymous Coward | more than 12 years ago | (#2823617)

When you have a customer sueing you for failure to meet a projected deadline, then you can tell him he should be ecstatic that your other 4 projected deadlines were correct.

Information theorists, and what they are trying to solve is interesting, I will agree. What they might be happy with is also interesting. But in the real world, people want real answers, and don't want to find out, in October of 1995 that Windows95 won't be shipping for maybe another 3 months, if lucky.

Real world consumers, and service providers do want 100% clinical accuracy in estimates. It seems that most people have forgotten what quotes and estimates are for. To most people in the real world, 80% accurate on an estimate is just as good as 0% accurate. The lawsuits, and penalties for going over budget, over time, or failing all together on 20% will outway the profits on the 80%.

So be happy that you can know that 80% of your school homework will be done when predicted. In the real world, no one cares about what you did in school.

The DEADline (1)

McD!ck (444861) | more than 12 years ago | (#2823624)

Can't all programmers have the same deadline that the guys at DukeNukem Forever have?


"It will be done, wheneven it is done"

Re:The DEADline (1)

tRoll with Butter (542444) | more than 12 years ago | (#2823748)

Come on, this one was obvious even before the vaporware lists took notice. The timetable is IN THE FREAKING TITLE! It will clearly take FOREVER.

Re:The DEADline (0)

Anonymous Coward | more than 12 years ago | (#2823752)

I tried that with my boss. Apparently that is "not good enough".

This is the wrong way round. (4, Interesting)

johnburton (21870) | more than 12 years ago | (#2823626)

In real life it's rare to be asked for an estimate of the time required.

What usually happens is you get told roughly what to build and the final date by which it needs to be ready. There then takes place a series of negotiations and compremises on the scope of work until everyone is "happy".

I suppose that doesn't really invalidate the point of the article at all, it's just an observation for those who think that estimation is the nice science that it is sometimes presented as being.

Re:This is the wrong way round. (2)

Gleef (86) | more than 12 years ago | (#2823821)

Yes, people want dates not lengths of time from the IS department. However, within the IS deparment, estimating the length of time a project will take is a critical piece of information to have when figuring out that date to tell people (or when to tell people the date they imposed on you just won't happen).

Re:This is the wrong way round. (1)

mark_lybarger (199098) | more than 12 years ago | (#2823831)

i would argue that the series of negotiations you mention include being asked for time estimates, then removing (or delaying till another release) functionality, squeezing down the testing, or whatever to get the project to meet the deadline.

Look at me... I'm a dick!!! Just like CmdrTaco!!! (-1)

CmderTaco (533794) | more than 12 years ago | (#2823632)

3 [goatse.cx]
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
63
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6
3
1
5
6
4
5
6
5
7
4
9
8
7
6
8
7
5
6
4
3
2
4
1
2
5
6
5
4
1
8
9
5
7
1
9
8
4
3
4
2
6
6
5
5
6
4
6
5
7
7
6
9
6
1
5
2
4
9
8
3
4
9
3
5
8
6
7
4
9
5
8
6
7
7
9
6
7
8
7
5
8
9
8
6
7
9
8
8
7
6
6
5
3
4
4
2
5
1
4
2
3
2
3
1
1
3
4
1
4
6
5
4
1
9
5
8
5
2
9
8
7
6
9
8
3
7
7
8
4
6
5
6
4
5
4
1
2
2
3
4
1
1
3
2
3
1
6
5
1
4
9
3
8
5
6
7
9
8
4
3
7
7
9
6
8
7
6
5
4
8
6
2
5
1
4
6
7
5
6
4
3
8
9
7
3
2
9
8
3
4
7
9
1
8
2
4
3
6
4
5
1
4
6
3
2
3
2
1
4
5
4
3
5
6
3
5
2
7
5
6
6
4
9
8
7
9
8
4
7
6
6
2
5
4
6

Reply coming right up... (3, Funny)

Baba Abhui (246789) | more than 12 years ago | (#2823651)

I'm going to have a great reply to this important story. It's going to have all the latest stuff - it will be broken down into paragraphs and have a high degree of relevancy. My reply will be ready in two weeks, give or take a month or so, if the powers that be decide it also must contain links and be spelled correctly.

ugh, timothy (-1)

LOTR Troll (544929) | more than 12 years ago | (#2823657)

I really do think that you're partially retarded.

What is being written (2)

cpuffer_hammer (31542) | more than 12 years ago | (#2823661)

The kind of development being done is going to have
a large part to play in how well the time and budget can be estimated. Projects that build applications automating known systems using strong toolkits should be more estimateable than leading edge mathematics and science driven projects.

When this comes up I always think or the evil officer pointing his gun at the scientist and saying "You will launch the new rocket by midnight or I will kill you." As if somehow stress will make the careful scientific work go faster.

I also wonder if this is a chaos problem. If someone could make really good estimates would knowlage of the estimate effect how the project is carried out causing the estimate to be wrong?
Or would being able to make good estimates cause management to under estimate even more often.

I would like to see results of projects estimated by a independent party that does tell the primarily parties of the results till after the project is finished.Would these estimates be correct more often.

What about methodologies vs. cost? (1)

jfsather (310648) | more than 12 years ago | (#2823673)

With all the hype surrounding XP/Agile/Name of the Week type development, I've been looking for hard numbers on how much better it is against older development styles. So far, I haven't been able to find anything accurate. It really comes down to multiple projects vs. performance. The is no hard data yet on the speed of XP against all project/component types. My biggest concern with this is that some manager will read up on XP, read a line that says it cuts your development time/cost by some percent and then draft a memo and adjust all targets.

Do these sort of numbers exist out there yet and is it even worth doing them given the theme of the article? Thanks.

tell TFA to RTFA (2)

MadAhab (40080) | more than 12 years ago | (#2823677)

Someone needs to tell the fine author of this article to RTFA [idiom.com] . Once you've read that, you realize this entire article is a straw man argument. When you know all of the factors involved, and you know FROM EXPERIENCE the likely production times of various parts, you can estimate with some degree of accuracy. But the point remains that whenever you have ANY unknown area in your project, you never know what you're going to find when you overturn that last stone.

And that's the point of a healthy pessimism in estimates; when the estimates are good, it's a matter of experience, not methodology. As you read through the comments on this article, you'll notice that everyone who has a method that sounds really sensible is relying on experience and the input of programmers, not on a pure methodology.

The best way to estimate (1)

L-Wave (515413) | more than 12 years ago | (#2823686)

THe best way to estimate is to give a shorter time frame, this makes the developers work harder (faster?), if you give a large time frame, they work slow. no im not management, im a developer, I jsut call it like it is. You always see people scramble and whip out code right before a deadline.

Re:The best way to estimate (0)

Anonymous Coward | more than 12 years ago | (#2823761)

That might work once or twice. After that, the programmers quit. I like it 9-5. So do you.

VidalSasoon

ommitted tasks (2)

joss (1346) | more than 12 years ago | (#2823690)

The trouble is that people always leave things out of the schedule. For instance maybe 30% of those reading this post are supposed to be writing software right now, but nobody in the schedule does it say "time spent pissing about on /.: 2 weeks".

Stupid topic, it depends what you're doing, duh: nth ecommerce site - predictable,
anything interesting (which by my definition means something that hasn't been done before) - unpredictable

The first rule of software schedules is things always take least twice as long as you think, even when you allow for the first rule.

Or to put it another way, the first 90% takes 90% of the time, and the remaining 10% takes the other 90%.

So, it's actually stupid to try to produce a valid schedule. If you estimate 2 weeks it will take about 4. You might think it smarter to change the estimate to 4 weeks, but then it will take 8, so you may as well estimate 2 weeks and be done with it.

I took advantage (0)

CrazyDwarf (529428) | more than 12 years ago | (#2823696)

I was working for a company a few years ago as an intern. My managers were not programmers by any means. I had such a plast at that job, because they would give me a programming task, and then give me a week for every day that it would actually take me to complete it. So for a project that would have taken me 3 days, they gave me 3 weeks. Of course, I always finished my projects early, but I took my time about it. I didn't want to be the one to make things worse for the next guy. I knew it was a short term gig, as it was technically and internship. I was always dead on with how long I thought it would take me, though.

I think when you're programming with something that you're familiar with, and have a pretty good idea of how to go about it, it's pretty easy for you to estimate how long it will take. I think for anyone else who is not as familiar with everything involved it would be harder, though.

SEI-CMM is a scam (1)

mbstone (457308) | more than 12 years ago | (#2823698)

Companies get certified in SEI-CMM (the Software Engineering Institute Capability Maturity Model) to get that government contract -- and then they quickly abandon or pay lip service to the CMM principles. The whole point of SEI-CMM is that you have to have a non-dilbert organizational structure in order to achieve "maturity" resulting in the organization's being "capable" of developing more stable code and of achieving more control over project costs and schedules. The irony is, the companies who need SEI-CMM certification the most, the big government and defense contractors, tend to be the same companies who foster immature corporate policies such as frequent mass layoffs, no training, illusory stock option programs, a culture of blame, and lousy HMO plans that don't cover anything.

There are limits, but you can still use your brain (2)

Ars-Fartsica (166957) | more than 12 years ago | (#2823701)

I don't think anyone believed that in a true, practical sense, any type of project in any industry could be quantified precisely. That said, many programmer/managers don't even take the common sense approach to scehduling.

First hint is to collect resonable metrics - even if you can't estimate a project, at least make sure you have some data to go on for the next one. Like defect rates, how much code is being generated or fixed per day, and so on.

Secondly, get programmers on the team to provide some tight resolution of how much they expect to get done...not in a month, but in a day. After a few days they'll start to understand how quickly they actually work and their estimates will get better.

Most of all, attach dollar amounts to things you do. Don't spend $1000 in engineering time to save $10 in computer time. Learn what resources are cheap and what resources are expensive.

There are many other tidbits which a common sense to most working programmers, but it doesn't seem that anyone employs them.

Scottie Method (1)

TechnoLust (528463) | more than 12 years ago | (#2823709)

Me: "Ah... I couldn't do it in less than 3 months captian."
Boss: "I need in 2 at the latest!"
(6 weeks later) Me: "It was rough, but I'm finished!"
Boss: "You're a genius!"

Actually, you tell him the real time, and he assumes you are padding and wants it twice as fast!

Your.com (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823712)

A few minutes ago, I loaded Slashdot and got your.com. Did this happen to anyone else??

This is all very nice, but... (0)

Anonymous Coward | more than 12 years ago | (#2823720)

If the specifications change in the middle of the development fase, all predictions will be useless... and when the client isn't sure of what he wants, then specifications will change... aLot!

roll some dice (1)

mydigitalself (472203) | more than 12 years ago | (#2823740)

as bizarre as this might sound, we are about to try a new estimation method here involving dice!

we practise extreme programming [extremeprogramming.org] (XP). To give you some context - we break software development down into 1 or 2 week iterations and break the work down into stories. These stories are written by people like myself, customers, and are estimated and by developers/engineers. Estimates range from half a day to about 8 days for the work. The benefit to the customer is in XP is visibility. Doing these small chunks of work we are always able to have a snapshot of the project and can massage it into place if things are looking bad.

so now to the point...
we are still finding that estimates, even though in bite/byte-size chunks, can be inaccurate. what we are looking at making the programmers do is give us a high and a low estimate for the work. We then roll a dice. If you roll a 1, you take the lower limit, a 6 the upper and so on.

this may sound totally crazy, but - i dunno - i've seen people spend months analysing a workschedule and still be MILES off the mark in terms of an estimate.

Sour Grapes (0)

Anonymous Coward | more than 12 years ago | (#2823747)

The author of this article is not disinterested in trying to convince an audience that he can teach others how to come up with reasonable (within 20%) estimates of development processes.

The point of the original paper was: There will never be a mechanical way to generate estimates of software development projects. I've never been part of a software project that was correctly estimated. How many have you been part of?

Effort estimation is Irrelevant (5, Insightful)

Markee (72201) | more than 12 years ago | (#2823750)

In the real world, any effort estimations are irrelevant anyway. I am sure everyone working in the business knows this situation:

Project manager says: "We have to add line item X to the project. What's the effort estimate for that?"

Me: "Twelve weeks."

PM: "But we need it in three weeks."

Me: "No way."

PM: "We have to. Shoot for" (names target date in three weeks).

Me: "Sure."

The due date is fixed, and the software development effort is determined by the available time afterwards.

Best solution is to sleep in airport lounge (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823753)

Date: Jan. 7, 2002
Subject: Airline Clubs

The use of airline clubs is a necessity. I belong to AA, CO, UA, HP. Lifetime each. I have always said that the clubs are an oasis in a sea of confusion. The clubs offer a quiet but efficient area to work or relax. The clubs will help you either change reservations or re-schedule flights with ease. I have always felt that I have a special friend in these clubs. You seem to always receive special service in the clubs.

When it comes to canceled flights or extraordinary delays the clubs are wonderful in dealing with this. You almost look forward to getting to the airport early just to use the services of the clubs.

Jon Katz

Let me get this straight... (1)

Aexia (517457) | more than 12 years ago | (#2823758)

*Half a year* after this article was published, this guy finally comes around to say "Yes, you *can* meet deadlines"?

I suppose it'd have been more ironic if he immediately produced an article that agreed with the original.

Firm delivery dates aren't a black art. (2)

Snowfox (34467) | more than 12 years ago | (#2823760)

I maintain that good programming is about 2/3 planning and about 1/3 development. So yeah, it's impossible to accurately schedule without a complete plan, because until you've done this, you don't know everything that needs to be written.

With a bit of experience under your belt, you can approximate up front, but anything claiming to be more accurate than an order of magnitude is somebody blowing smoke.

That said, an honest and honorable programmer will always do one of two things: (1) swallow his or her pride and give the high end of the above estimate, or (2) knock as much time off the high estimate as he or she is willing to compensate for by putting in the extra hours UP FRONT to deliver in the timeframe promised.

PSP ties in with CMM (1)

batboy78 (255178) | more than 12 years ago | (#2823765)

In my last shop we spent a lot of our time working on acheiving CMM level 2, which was harder then it sounds for a bunch of hackers. As we were approaching our level 2 goal, Carnegie Mellon offered us their Personal Software Process class. It ties in closly with the rules and guidelines set by the CMM, but it focuses on your own abilities. By keeping metrics on time spent coding or time spent documenting you can learn the rates at which you are able to work, and can apply that to estimates with reasonable accuracy.

Lewis' conclusions are incorrect (1)

clsv (550200) | more than 12 years ago | (#2823770)

The paper 'Large Limits to Software Estimation' intermingles program size and minimal program size. The latter can not be created/computed within reasonable time.

So, in general, the time necessary to program a piece of software of minimal size is well-known. Thanks to Kolmogorov complexity.

As far as I know there are no specific K-complexity proofs about the (time/space) complexity of programs larger than minimal size.

This invalidates the conclusions in the paper. So keep on creating and testing software metrics!

Stating the problem is the first stumbling block (1)

Vingborg (141225) | more than 12 years ago | (#2823771)

Any formal estimation method, if possible, even if only partial, would still require a formal description of the task, which is, in my experience, the first and foremost problem/art/craft in software engineering. Once the task is adequately defined, the remaining work is, by and large, downhill.

Ok, the definition of "adequate" may kick off a few debates, especially with management... which, in my experience, is the central "problem" in software engineering. Management, that is.

Hmmm...

Programmers are not machines..... yet.... (4, Insightful)

Reeses (5069) | more than 12 years ago | (#2823776)

Every article I've read on this overlooks one thing that every programmer requires a small amount of.

Creativity.

It's something that's hard to be measured. Sadly, programming is not like assembling a car, where it can be broken down into infinitesimally smaller chunks, then added back together to get a whole.

For example: it takes six seconds to put this screw in place, so we'll stop the assembly line for 8 seconds, then the car moves on regardless, under the assumption that the screw was inserted.

Programming is not like that. I know I've stared for an hour at the screen trying to figure out why one line of code wasn't working.

Or sat there for a while trying to figure out how to approach a problem before writing another line of code.

Likening programming to a production line is not good. There's no way to know in advance how many lines of code there are going to be, nor how long each line is going to be. If you knew this, you could add up how long it would take the average person to key in the strokes, and there's your estimate. That doesn't work in software.

For time usage, software needs to be compared to any other creative process as opposed to a mechanical one. How long did it take daVinci to paint the Mona Lisa? An hour? Two? 3 days? Could he have guessed from the outset that it's going to take x amount of time? Probably not. He might have been able to give a ball park based on how fast he's painted similar stuff in the past, but he couldn't nail it down exactly.

Now, granted, as you develop time and experience, your estimations get better. In addition, yor time to completion gets better. (How long do you think it would have taken daVinci to paint a _second_ Mona Lisa? A lot less time than the first one, because he's done one, and he remember how he solved various problems, like how much of each color to mix to make a certain tone.) This is where talent and experience come in.

But until software becomes similar to assembling Lego bricks (which it will, one day, and has in some places), then it's going to be hard to quantitatively determine how long a given project will take. And even if it becomes like Lego stacking, there's still going to be some fudge factor because how to solve the problem has to be solved before solving the problem.

And sometimes you have to tear apart and start over because a brick is out of place, or it's just poorly designed.

It's true, but don't let it stop you from planning (1)

gpinzone (531794) | more than 12 years ago | (#2823781)

All development and estimation methodologies are going to rely on human estimation at some point. A realistic Work Breakdown Structure diagram needs to be drilled down until the tasks are less than 5% of the total project time. Even still, the estimates of those tasks are still going to be based on human perceptions of how long that particular task will take to accomplish. The estimates of each individual task may be inaccurate especially if they involve doing something that's never been done before. This is where the errors crop up. It's those tasks that I agree can't be predicted with a high level of accuracy.

However, this doesn't imply that you shouldn't try to plan your project instead of diving right in with coding. There are plenty of tasks that can be predicted accurately. Even if they do take longer than you expected, at least you broke the project into small chunks. You can manage the slip on a week-long task much easier rather than try to do damage control after a month of development and no results. Furthermore, if your milestones aren't met on the dates you predicted and they aren't on the critical path, you can let them slide without impacting the project. If you never plotted out the project beforehand, you'd never know.

Incremental timing. (1)

Dutchmaan (442553) | more than 12 years ago | (#2823783)

Developers should issue release dates at various points in the project. An initial release estimation which is basically worthless but gives you an idea of what the company has in mind for release. A point at which the project has reached beta stage and how long they will expect it to be in beta. This can be taken with a grain or two of salt, but should give a more accurate estimation on the true release date.

I'm sure there can be other points along the line, but you get the idea. Granted this is kind of how things are done now, but not standardized at all.

3 Big snags in time estimates (5, Insightful)

corvi42 (235814) | more than 12 years ago | (#2823798)

In my experience, the biggest snags in all time estimates have to do with the under-determination of what a project is and what it involves. Given any project F which has only F(x) parts to it, you usually have some rough intuitive estimate that there will be G( F(x) ) bugs to work out. Given that you are familiar with the type of project involved the estimations are generally fairly decent.

The big problem is that in real-world applications, x is always changing. I have found that the culprits of this is mostly one of several things:

1) You're not as familiar with the project as you thought you were - or there are some aspects that are familiar, but the unfamiliar ones have ramifications you don't foresee because you're not familiar with them. This adds to both your estimations of F(x) and G(F(x)).

2) Users are dumber than you thought. The difference in mindset between the user and the engineer is real and very significant. There are things that as an engineer ( especially one who is working closely to a piece of code for months on end ) you would never try to do with a particular application, and yet a user who has never seen it before will do out of ignorance or confusion or both. Just when you think you've made something idiot proof - they invent a bigger idiot. This throws off your estimates of G( F(x) ) because you have whole classes of bugs you never thought of as bugs before. Sometimes this requires reworking core components making estimates of F(x) go wrong.

3) The client either doesn't know what (s)he wants, or doesn't know how to explain it, or even that it is necessary to be explained. This is the most frustrating of problems, and can be fatal to entire projects. Often clients don't think of software engineering like real engineering. One cannot ask an architect to redesign a building after its already 3/4 built. But this has happened to me with software projects, and even on occasion prompted me to quit a job in frustration. When this happens, all bets on estimates are off.

Either that or I'm just really lousy at doing time estimates =)

Estimation isn't all that difficult (5, Insightful)

pubjames (468013) | more than 12 years ago | (#2823803)

As someone who has to provide estimates to different clients for different types of jobs on a frequent basis, I have to say that I don't think it is as difficult as some people make out.

The secret is to base your estimate on a detailed specification. Specify in detail, break down the big task into smaller ones, estimate for each smaller task, add up, add 10% for contingency.

I think the problem is that too many estimates are made on the basis of poor specifications, then you get a shock when you discover a problem you haven't anticipated. So, my top tips:

1) detailed spec agreed with client.
2) breakdown into smaller tasks.
3) estimate for smaller tasks.
4) add up and add 10%.

All this stuff about doubling etc. - what are you people like? If you have to do things like that then perhaps project estimation isn't something you should be doing...

A little knowledge hurts... (0)

Anonymous Coward | more than 12 years ago | (#2823804)

Wow.

It's this kind of thing that makes me really worry for the future of the world. The first guy(Lewis) says there's no rigorous mathematical method for estimating software development times and the second guy calls him on it and than goes on to prove Lewis correct. A statistical method that produces 50% correct answers 50% of the time is not a method that I would claim fits the model that Lewis "proves" can't be developed.

As far as I can tell Lewis doesn't claim that the search for a method for estimating development times is useless but only that you'll never find one that gives 100% accuracy 100% of the time, i.e. a method that is deterministic.

Than the second guy goes "oh yeah, I'll show you, we'ld be happy with a statistical method that's 50% correct 50% of the time". Huh? Let's play that again?

Statistical methods for estimating software development times are basically the aggregated knowledge of history, i.e. a semi-formal method of canning a good experienced developer. Again, that's Lewis' point.

d00d (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2823850)

heya

The real problem... (2, Insightful)

Christianfreak (100697) | more than 12 years ago | (#2823861)

is PHBs who want the software done yesterday.

I develop web applications in a small town. My boss comes to me and gives me specs on some new project. I look over them and give him a quote, say 40 hours, he then proceeds to laugh and say that the client will never pay that much for the app. So we spend an afternoon looking at what we can cut, trying to reuse code, maybe take out a feature or two here and there and come up with half the quote (20 hours) which I tell my boss we can make unless problems arise.

As with all development, problems arise, the client complains about X feature stuff gets redone, the code ends up being a huge mess and usually takes 1 and a half times the original quote.(60 hours). Yet my boss still doesn't figure it out. Why? Probably because his boss keeps breathing down his neck to cut development times as well.

What's worse is when a sales person or my boss talks to a client and gets them to agree on a list of features and the time it takes to develop before even consulting me. Last month a client wanted a content managment system for a website, discussion forums, polls, etc. Because of certain features it couldn't just be downloaded and I ended up just writing it. The client was charged 25 hours, it took closer to 80.

Anyway its the PHBs that cause the problem
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>