Slashdot Mirror

← Back to Stories (view on slashdot.org)

Are There Limits to Software Estimation?

Posted by timothy on from the semantics-and-realities dept.

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.

4 of 225 comments (clear)

  1. Unless it's a simple project... by Nijika · · Score: 5, Interesting

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

    --
    Luck favors the prepared, darling.
  2. 2x+7 by Lizard_King · · Score: 5, Interesting

    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.

    --
    "My mother never saw the irony in calling me a son-of-a-bitch." - Jack Nicholson
  3. Accuracy, and doubling a double by CDWert · · Score: 5, Interesting

    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.

    --
    Sig went tro...aahemmm.....fishing........
  4. Programmers intuitively know this by Anonymous Coward · · Score: 5, Interesting
    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.