Follow Slashdot stories on Twitter


Forgot your password?

How can a Developer Estimate Times? 227

SubliminalVortex wonders: "Many times in the past, I have been asked on 'how long' it would take to implement a certain features/fixes in a product. What's interesting is that many times, certain 'fixes' is adjusting the wording/placement of the items in question; in other cases, users want the product to do everything they ever imagined, since it already started by following their line of thought. From there, the problem continues. From the user interface, people 'imagine' and think that 'oh, it would be easy if...' and scenarios occur, not only internally from the company using the product, but the clients themselves. Usually, several good ideas are there, but estimating times is a pain in the arse if you have a platform you're writing code for which has no documentation. How do coders estimate times to their bosses? If I know the answer outright, I'll give it, but in some cases, I don't how much time I'll take from other developers *because of the lack of documentation*. I'm going to have to bring in my D&D dice next week just to start."
This discussion has been archived. No new comments can be posted.

How can a Developer Estimate Times?

Comments Filter:
  • by AuMatar ( 183847 ) on Saturday July 01, 2006 @11:37PM (#15644440)
    The only way to tell is to design the feature, then guesstimate how long each part of the process will take (by comparing it to how long similar problems have taken). If there's a step you're unsure of, you need to be sure of it to give a reliable estimate. Then double it- something will go wrong, and its better to deliver early than late.
    • This is really an excellent method. I've been asked to estimate the time it will take to develope a system that is likely to take about 500 hours and is completly new and customized to the client. The only way to do this is to get a detailed feature list from the client (or boss) and break this down into known units which you have experience in building. This allows the most accurate possible estimate as it reduces unexpected parts (you've defined everything already) and allows you to incorperate this ne
      • To add to this, you should also schedule work on the riskiest parts (time- and resource-wise) of the project first (at least where this makes sense). That way if something comes up that might affect the release, you and the client will know sooner rather than later and be able to deal with it more effectively.
    • I agree with parent post. I'm asked this all the time because I'm a lead developer at the company I work for. If I can't provide an estimate on the spot, I tell them I will have to get back to them about an estimate. I try to buffer for time for bugs and QA. Bugs are things you just can't account for. You may have none, you might haave tons. You have that one bug that takes forever to diagnose, or you might have 20 bugs that you can knock out each in minutes.

      Just try to be fair in your estimate; fair for yo
    • I have a serious limitation in the ability to predict such things. How can you design something without doing most of the work to have it completely done? If there were similar problems, how can they be so similar that code reuse doesn't factor seriously into the would be estimate, and yet be so different as for the new code to take a significant amount of time?

      I have a sentence for this: I can't remember the future.
      • by AuMatar ( 183847 ) on Sunday July 02, 2006 @04:17AM (#15645035)
        Design it on paper. When you design something, do you jump up and code it? If so, thats a problem to begin with. Design it out on paper- any new major (external facing) methods, objects, etc. Major algorithms have to be identified, but not coded especially if it requires something totally unique. Design is a skill in and of itself, and takes practice. For the purpose of an estimate, you should have it done to the point where you could sit down and code with only minor decisions made at code time (until the point where you find the thing you didn't account for- nobodys perfect), but no code actually written.

        As for comparing time- first, you have prior experience. Having done something similar on another project can give you a good idea as to time. Then there's similar things to another part of the program. Finally, just because something is similar doesn't mean the code can be shared. But it does give you a yardstick for time.
    • The "Then double it" rule has always worked well for me. Actual time taken tends to be somewhere between what I originally thought, and the estimate I give, so it looks like I've done the work faster than expected, which is good. Also, if I'm told to rush something, I can generally get it done in well under my original estimate, which makes people happy. Sure, the boss learns fairly quickly that you're giving worst case estimates, but I think that's a lot better than giving best case estimates.
      • by Glonoinha ( 587375 ) on Sunday July 02, 2006 @12:41PM (#15646104) Journal
        Actually 'then double it' is only for experienced developers.

        Newbie : 8x as long as estimated.
        Seasoned Developer : 3x as long.
        Elite Veteran : 2x as long.

        Here's the rule I use when dealing with developer estimates (copied from a post almost a year ago) :

        Time estimage guidelines:

        New programmer fresh out of college: Take his estimate and multiply by 8x. Yes he could get it done in 1 day, assuming he got so cranked up on caffeine his eyes stopped blinking and he worked on that (and nothing else) for 24 hours straight. In the real world a newbie can dedicate about 2 real hours doing a particular task each day, the rest is spent coming up to speed on corporate coding standards and libraries, email, breaks, and not 'in the groove'. Also, you are expecting him to document it but he didn't account for that in his estimate - his estimate was only for time to code the actual lines of code.

        Veteran programmer of average skill, single person project : multiply his estimate by 3x. A third of his day is spent hand-holding the newbie, and another third is spent hand-holding management. The other third is spent programming, but luckily he knows to pad the schedule some (not enough, but some.)

        Veteran programmer of uber skill, single person project : multiply his estimate by 2x. This is as good as it gets. A uber veteran programmer knows to leave his email client closed and his door closed so he can stay in the zone. He knows to pad the schedule more than he really thinks he should. And it still takes him twice as long as he expected.

        Multiple people working on the same project : increase the timeline by a factor of 1.2 per additional person. If two people ought to be able to do it in 10 days it will take 12. If 11 people (10 additional) ought to be able to do it in 10 days it will take ... 1.2^10 = about 6, so 10 x (1.2^10) = roughly 60 days = 12 weeks = 3 months.
        • "Also, you are expecting him to document it but he didn't account for that in his estimate - his estimate was only for time to code the actual lines of code."

          Ah, yes. Stealth requirements. The seasoned developer will be familiar with the practice of requirements which you didn't mention, and when asked about them, will say, "Well, that goes without saying!". And it's true, it *did* go without your saying it... ;)
        • Comment by Anonymous Coward in the room with me:

          Double it, then change the unit. If you think it'll take an hour, say "two days". If you think it will take two days, tell them "four weeks". If you think it'll take a week, say "two months".
    • I've never been a developer, but I've been a tester, and this is the way we used to estimate how long a testing job would take. Basically, we would estimate how long it would take us to do the job if everyone left us the hell alone and we were able to concentrate entirely on that job. Then, we'd quadruple it because, inevitably, something would come up and we'd have to deal with some other random thing on some completely different application.

      Of course, that's for apps we're already somewhat familiar wi

    • Really, this question only covers half the issue. Along with any estimate of development time comes a degree of confidence, which a manager can use in coordinating tasks. For instance, for a given task, you could say:

      1) Best case, 20 hours (25% certainty)
      2) More likely, 40 hours (50% certainty)
      3) Most likely, 60 hours (75%)
      4) Worst case, 80 hours (95%)

      In other words, any estimate should be given along with that degree of confidence. That way, if the manager requires something more certain, you have t
  • Nature disguises weak products as Beta []
    • You can always do what management does: you pull numbers out of your ass.

      The only problem is that, unlike them, you may get held to those numbers...
  • by sakusha ( 441986 ) on Saturday July 01, 2006 @11:39PM (#15644447)
    The Estimator's Rule:

    It always takes longer than estimated, even after accounting for the Estimator's Rule.
  • With the Scrum development process, the requesting parties are able to get feedback every 24 hours. The development team's does not commit to delivering more than they believe can be achieved in thirty days. See if you can get your bosses to buy in. Here's a website: []

    • We're using this at work at the moment, just as we start up a 10 month project development cycle. I'm skeptical, because for the same reason 30 days of development estimted, might really be 60, 2 days of development might really be 4.

      From what I've seen so far, they just wanna know how far along we are, not how long we think it might take.
      • "I'm skeptical, because for the same reason 30 days of development estimted, might really be 60, 2 days of development might really be 4."

        Yes, but it's better to know in two days that your estimate is wrong than wait thirty days. Also, a lot of SCRUM is breaking things down to an understandable level. I.e. down to problems like, "Design the initial schema for the main database table" rather than problems like "Define the database schema for the project." It's much easier to determine how long it will tak
      • In general, the more, and the more often, you do something, the better you get at doing it. Finding out that it took you four days to accompish the task you thought would take two days is a signal to re-examine how you estimate. Breaking things into two-day tasks instead of thirty-day tasks means that at the end of a year, you will have performed 125 estimates instead of twelve. You think your 126th estimate might be better than your 13th?
  • ...use a random number generator? :)

    More seriously, I've found from past exeperience you should always take whatever time you think the project will take and multiply that number by 2 or 3. If you are lucky (and the customer requirements don't change to much) you should make it.
  • Experience (Score:5, Insightful)

    by fitten ( 521191 ) on Saturday July 01, 2006 @11:40PM (#15644452)
    Two things really... you have to break your tasks down into small tasks with known dependencies to the point you *can* estimate times to do things. Once you get that far, experience (gut feeling) will contribute. After that, you give an optimistic and pessimisitic times to your boss. Example: If all these assumptions hold and these other three things happen on time, then the time estimate is one week. If this, this, or this doesn't pan out as expected, then the time estimate is three weeks.
    • To break it down sufficiently will mean you'll be doing all the developing except the actual code and testing.

      Who's paying for that?

      • Nah- you can usually give some sort of estimate.

        "Let's see; To implement that, I'll need to write & test X, Y, and Z. I've done things like those before; It'll be.. hour for X, two for Y, two for Z; That's five hours..."

        "So, if nothing unexpected happens and if nothing goes wrong, I think I could do that in about 5 or 6 hours."

        Now, it may well happen that you finish in 3, or that you finish in 20. You may have forgotten to factor something in. Regardless, it's just important that your client (or boss,)
    • > have to break your tasks down into small tasks with known dependencies to
      > the point you *can* estimate times to do things.

      Also, Cliff, don't forget to account for the fact that some of these tasks are also interdependent, and count time to integrate the components created and test them.

      > Once you get that far, experience (gut feeling) will contribute. After that, you
      > give an optimistic and pessimisitic times to your boss. Example: If all these
      > assumptions hold and these other thre
  • Why are you writing for a platform with no documentation? Either the platform was developed in-house, in which case the respective team should be shot, or you're licensing it from some company that should have written documentation already (otherwise you're paying too much for it, even if it's free).
  • by Steamhead ( 714353 ) on Saturday July 01, 2006 @11:46PM (#15644462) Homepage
    To take a leaf from Star Trek just do what he always did. Say it will take 3 times as long as you think it will, and you will always get half that time to complete it. And if you get it done early you will be rewarded.

    • Re:Good 'ol Scotty (Score:3, Insightful)

      by Osty ( 16825 )

      To take a leaf from Star Trek just do what he always did. Say it will take 3 times as long as you think it will, and you will always get half that time to complete it. And if you get it done early you will be rewarded.

      I think you left something off at the end. "And if you get it done early, you will be rewarded with even less time for the next project."

  • by RedOregon ( 161027 ) <redoregon&satx,rr,com> on Saturday July 01, 2006 @11:52PM (#15644476) Homepage Journal
    Count how many dumbshit managers with no technical knowledge you have over you.

    Double your realistic estimate for each DM.
  • No Easy Answers (Score:2, Interesting)

    by Dunx ( 23729 )
    I've been developing as a job for almost twenty years, and I still don't know the answer to this question.

    The best approach I've found is to decompose the problem into chunks that are small enough to give a reasonable estimate of, but I've hit two snags with this:

    1. it may take time I don't have to do the decomposition

    2. managers don't like big numbers

    Good luck!
    • Re:No Easy Answers (Score:4, Insightful)

      by Duhavid ( 677874 ) on Sunday July 02, 2006 @12:20AM (#15644556)

      I would add, dont let them sucker you into making
      an estimate without doing the decomposition, if there
      are items that are risky because it is something
      newish, allow time ( up front is best ) to do some
      empirical development to figure out how it all works,
      and if you normally pad estimates with a x 2 factor,
      pad this part with a x10 factor.

      *Dont* succumb to the temptation to cut back any
      estimates once you see what the totals come out
      to. Do your estimation at the "leaf nodes" only, and
      let the numbers come out as they come out.

      And even if the managers dont like the big numbers,
      at least *you* will know. They may well tell you you
      have less time than you asked for. Dont agree when
      they come out with the "it wont *really* take that
      long, will it?" stuff. Stand your ground, but realize
      you may not get the time. Then you can pre-prioritize
      how you execute on the project, so that the most important
      stuff is done ( hopefully ) when their stupid deadline
      comes up. Now, that does not mean that you should be
      disagreeable in your disagreement. But when they
      throw on the pressure to bring forward the deadline,
      find a way to remind them that you are working toward
      that deadline, but you dont think it achievable. Course,
      then they will try the "we cant have you lead unless you
      buy into our stupidity" kind of stuff. Dont have
      an answer to that.
  • Just Google "software estimation" and you get a variety of ways of doing it (the most popular formal model is COCOMO). In the real world, most people don't have the luxury of doing estimates the right way. In my experience, the stakeholders want a good guess at first (aka SWAG, OOM, VROOM, LOE). They treat that initial guess at the high watermark and then expect you to either finish early if all went well or finish on time if there were problems.

    How I go about making this initial guess is by breaking the pr
    • adjust from the baseline for that component based on the engineer's performance level compared to mine

      Another, similar method I have seen mentioned, I forgot where:
      Everytime something is coded, ask the coder for his estimate, and compare that to the actual time it took when the job is done. With this method you can over time develop a multiplier (on average, and for each individual coder) for the estimates given. You can even assess the accuracy of an estimate based on the variance of the estimates.
  • by Osty ( 16825 ) on Sunday July 02, 2006 @12:00AM (#15644496)

    For the most part, your ability to give an estimate on a change is a matter of experience. General experience will give you a rough idea of how long it would take to implement some random feature. Specific experience with the system in question will give you a much more refined ability to make an estimate. If you can't make an estimate, or you can only make a rough estimate, be upfront about it. Tell your manager or the customer (if you're the one working directly with the customer) that your estimate is very rough, and try to add as much buffer time as possible. Also, don't get into granular estimates when you can only give a rough SWAG (Some Wild-Ass Guess). If you think it'll take you an hour, say a day. If you think it'll take you a day, say three. If you think it'll take you three days, say a week (experience will tell you how much buffer to add). If you don't have enough experience with the system to make a good estimate, ask your co-workers for help. It's always better to under-promise and over-deliver than the other way around. Besides, while you may end up over-estimating some feature, chances are you also underestimated another one and the extra buffer time you don't need for feature A will be invaluable to finishing feature B.

    To help you make better estimates, you should make sure you get a solid set of requirements from your customers. Time should be spent with the customer to determine exactly what it is they want (they may not be able to articulate it clearly), and whether or not there's already a solution they could use if they're only willing to change their process. Avoid telling the customer at that point whether something is "easy" or "hard" (and definitely ignore them when they suggest something will be easy -- they don't know the inner workings of the code, so how will they know if it's hard or easy? Changing a piece of text may look trivial, but may involve a number of external factors such as localization or legal that would turn a 5 minute fix into a two month battle). Take what you've learned, distill it down into a solid set of requirements, and take that back to the customer for sign-off. Once they've signed off, they don't get to change their mind any more for this cycle (however long that may be -- days, weeks, months, or even years, though hopefully not nearly as long as that). Then you get rough estimates from the developers based on their gut feelings and knowledge of the code base, and have them investigate deeper to solidify those estimates. At that point, you have enough to build a schedule, but allow for buffer time! A developer's 8 hour day may not be 8 full hours of coding. It may be 4 hours of coding, two hours of meetings, an hour for lunch, and an hour of "filler" for the cost of task-switching depending on how the coding hours and meeting hours overlap. Based on your experience with past projects, you should have a good idea of how much time per day a dev actually gets to spend on coding and use that to build your schedule. For example, developer estimates are all in 8 hour day increments, but you know from experience that developers average 6 hours per day of productive work. That means a 5 estimated days will actually take 6.7 real days, so use that as your buffering criteria. (BTW, six hours of productive work is actually high. In most cases, it's really closer to 4 or 5.)

    Finally, don't forget QA. Just because a developer has confidence that he can implement a specific feature in one hour doesn't mean it won't take QA a week to verify all of the ramifications of that change. You really need to have your QA team working in lock-step with your dev team. Your dev team should write technical specs on the features, and your QA team should estimate impact off of those. The "agile" disciplines that are en vogue lately try to incorporate testing directly into the development process, which is good. However, that means that developers will be in charge of including QA costs on their estimates, which developers are usually bad about doing

  • He said "double it then raise it to the next unit of time."

    One hour becomes two days. A week is two months. A month is two years.

    P.H.: If you are reading this I'm still in the business.
  • Be Honest (Score:5, Informative)

    by bhmit1 ( 2270 ) on Sunday July 02, 2006 @12:03AM (#15644508) Homepage
    As others have said, you should estimate based on similar tasks, and then overestimate before giving that number to management. But there's also something to be said for being honest. Most management types I've dealt with are just fine when you say "I don't know if the application allows us to make that change quickly, so let me do some research and get back to you tomorrow with an educated guess." It helps if every so often you come back to them before the end of the day and say that it was an easy change and you've already finished it. Finally, when working on more than a few things at once, I make sure there's a prioritized list that I'm working from that management is aware of (so they understand why the latest request will take more time) Also, I make sure there's regular progress on one or more high priority items. Management and customers always sleep better when they see forward momentum even if the deadlines slip a little. Spending a week with nothing to show makes them nervous even when things are on time.
  • Giving an estimate is really giving an expectation. I try to answer the estimate and share my confidence level of that estimate. Plus I try list any caveats that might impact the estimate. If I tell a boss something will take about a week, but I don't have much confidence in that estimate because I don't understand what the user is looking for, that much better than guessing two weeks and finishing in one. I find bosses to be far more understanding of missed deadlines if they have a reasonable expection
    • I try to answer the estimate and share my confidence level of that estimate. Plus I try list any caveats that might impact the estimate...I find bosses to be far more understanding of missed deadlines if they have a reasonable expection of missing a deadline.

      Exactly. In fact, at that point it's more of a goal or projection than a deadline. It only becomes a deadline if you, your boss, or the customer make it firm. You can't control your boss or the customer, but if you imply that it's firm when your confid

  • Come up with your estimate as usual (I'm talking your REAL time estimate, coordinating with your team members, not using the schedule handed down from on high PHBs)
    Multiply by 250%

    Add at LEAST two weeks on top of that.

    Tell your (un)friendly PHB "the schedule is NOT negotiable (for acceptable quality) unless they start cutting back features, oh and as a friendly reminder, PHB, throwing more programmers into the mix this late in the game will NOT speed things up, and outsourcing it whole or in part to India c
  • This is my method : I list out all the steps necessary for the task to be completed. I then make an initial estimate on how long each task should take. I then go back over the list and add a confidence interval which is a percentage certainty that I am on how long each task should take. I then create a min/max time for each task based upon the confidence interval.

    Draw a line through the min column. Min column is just for amusement. Total the max column and then double it.

    If you feel like you need more fudge
  • You know, Wild Ass Guess.
  • by bitbucketeer ( 892710 ) on Sunday July 02, 2006 @12:20AM (#15644553)
    If a client insists on an accurate estimate of "how long it will take" for a non-trivial project, then you pretty much have to get them to provide you with or pay you to generate a requirements spec, a functional spec, and then an implementation spec. From the implementation spec, you can then ballpark how long each part will take to code and test. If the client balks at putting exactly what they want on paper, then you should balk at providing any kind of estimate; because there is only one truth in that situation: it will take as long as it takes.
  • by moranar ( 632206 ) on Sunday July 02, 2006 @12:33AM (#15644584) Homepage Journal

    This might help: Painless Software Schedules [].

  • Okay, so here's how I do it:

    First start with one day: this is for a single page of static HTML with graphics.

    For every buzzword the client uses, multiply by ten:

    Can we have some Flash? (ten days)
    And AJAX, too? (100 days)

    Am I serious? You decide.
  • Estimate the time you think it will take and multiply by 1.5 to 2.0. You need a fudge factor for unforeseen problems, scope changes and so on.

    It is better to overestimate than underestimate. For example, let's say you get a big fat contract with an open checkbook. Now if you go over the estimated time you or your employer may have to eat the difference. The person signing the check may call bullshit on the over budget project, and refuse to pay the difference.

    Finish the scope of the work early and your
  • If you're developing an application where there are a bunch of forms and workflow spec'ed out then you take a statistical sample of the forms and get them running with the development tools you are using.

    At the other extreme, if you're developing a "platform" you're in the realm of philosophy or mathematics where it matters more how well you conceptualize the system and you should probably just forget about estimates and go for quality. Yes, that means you can't go to VC's for financing deep system softw

  • Steps that help (Score:3, Insightful)

    by Beryllium Sphere(tm) ( 193358 ) on Sunday July 02, 2006 @12:45AM (#15644619) Homepage Journal
    Don't expect anything on this list to solve your problems.

    o Break the problem down into small pieces. If you have an item on your schedule that says "Do X" and the estimate is "two weeks", you do not understand what X is. Keep splitting it into X.1, then X.1a, then X.1a.ii, until the pieces are all less than three days, preferably much less.
    o Clock time != development time. You will spend half your time going to meetings, preparing TPS reports, and making phone calls to find out why your test server is down. To convert development hours to schedule hours, use a factor of two.
    o Keep an estimator's handbook. Ever noticed these in a technical bookstore? You can look up how long it takes to plumb a bathroom, build a wood frame wall, etc. Keep your own list of how long it takes to build a credit card form or a bulletin board. Look up the phrase "function point" in ancient literature and see if you get any useful ideas.
  • by stienman ( 51024 ) <.adavis. .at.> on Sunday July 02, 2006 @01:06AM (#15644666) Homepage Journal

    Time estimation is part of project managment. A good course in project management will give you the tools to effectively deal with these situations.

    Short and sweet, when asked to give an estimate (any estimate) ask them if they want the quick and dirty estimate now (which may be off by 1,000% or more) or if they would like a more accurate estimate. If they want the quick and dirty then use whatever method you use now to give them the estimate. If they want an accurate estimate then tell them you'll research the current state of the project, the development effort required for functions x, y, and z, and the resources required to accomplish the effort.

    Then follow a good estimating process - there are many available in many books about this subject. In my case generally new projects are very similar to older projects, and are all built on the same foundations so it's easy to start with a list of tasks to get from point A to B, and list the resources and dependencies for each task. Link them all together, and then go to the boss and say, "Assuming that we have these people and these reources, the project will be completed x weeks from kick-off."

    When (not if) the boss says, "Well it needs to be done by this date!" Calmy reply with, "We can meet that goal by either scaling the work back, or increasing manpower. Which is more suitable for this situation?" and so on.

    The one thing you don't want to do (that all too many software engineers do on a regular basis) is over estimate or underestimate the work required. In either case the customer (generally your boss) learns not to trust your estimates. This is bad on so many levels, and is the main reason that so many software engineers work more than 40 hours per week on a regular basis - especially those that overestimate the time required trying to combat this (paradoxically).

    A more accurate estimation process will include a frank discussion of risk and risk management. "This schedule is good as long as we assume the code base is well documented and follows reasonable coding practises." Then find out what the customer wants you to do if you find this assumption to be false. Give them the whole scenario - the risk may be low, but if the assumption proves wrong then perhaps the project schedule or resources just tripled. That may be too great a risk to take even if it's unlikely - so how do we mitigate that risk?

    I could go on, but really this is a basic question that millions of people have asked for thousands of years. There are much better and more thorough resources to answer it. Visit your local library if your company isn't willing to send you to a simple three day project management seminar. They won't teach you much that's new, but they'll tie it all together and give you the tools you need to communicate effectively with others - most of the important stuff is being able to say, "I'll get back to you on that by thursday."

    • Time estimation is part of project managment. A good course in project management will give you the tools to effectively deal with these situations.

      Hmm. Then why, depspite years spend working under PMs who'd taken all sorts of courses, have I encountered so few who could deal?

      In my case generally new projects are very similar to older projects, and are all built on the same foundations

      Then the problem is trivial. What about the general case?

      I could go on, but really this is a basic question tha

      • Hmm. Then why, depspite years spend working under PMs who'd taken all sorts of courses, have I encountered so few who could deal?

        If a few students fail in a class, one would presume it's the student's fault. If the majority of the students fail, then one would presume that the teacher is at fault. (or it's an engineering 'weeder' class :). Project managers who do not have expertise in the project cannot do the time estimate. They can only go to the experts and help them break the tasks up and estima
        • In the case where even that's not possible (You are not expert enough to break a given task up any further, or redefine it so that it you are able to break it up), then the correct estimate is, "We do not have the skills to properly estimate this project."...Does this adequately cover the general case? If not, where does it fail?

          The problem you're ignoring is when the lack is not in skills or expertese, but in information about the problem.

          You can't break a problem down until you throughly understand

  • DON'T DO IT! (Score:5, Insightful)

    by MarkusQ ( 450076 ) on Sunday July 02, 2006 @01:21AM (#15644685) Journal

    Don't do it!

    I'm serious. If we've learned anything over the past forty years, it's that trying to estimate software development time is a waste of time. Why? Well, for one things, bugs. To know how long it would take to find and fix them, you'd have to know what the problem was, which means the hard part's done. For another thing, specification flux. Most reasonable project specifications for non-trivial projects don't provide enough information to accurately predict how long it will take to code. And producing such specs, and using them, will take longer than the development would have taken in the first place. And, if that's not enough, think of Dilbert. Specifically, the one where his boss asks him "Will there be any unforeseen problems?"

    I once told a client (a dot com) "I'll tell you how long this will take if you can tell me what you stock will be worth six months from now, four months after you IPO. And I'll be more accurate than you will. If you'd rather, you can tell me when the next two-day rainstorm will be." He hemmed and hawed, and basically refused to give any sort of number whatsoever. I said "Good, it looks like we've got a nice honest relationship going here. Neither of us is willing to lie to the other, or claim to know something we don't. So let's start prioritizing these features for the mock up."

    Let me say it again: Don't even attempt to estimate development times.

    So what should you do instead? Incremental development with frequent opportunities for feedback. Ideally, the users should be able to play with a nightly-build prototype whenever they want from the first week or so on. If they ask for a time estimate, tell them it will be done when they're happy with the result, and don't want anything more, or they're unhappy with the rate of progress, and call the whole thing off.

    But don't lie to them, no matter how hard they push.


    • Partial agreement... (Score:5, Interesting)

      by pVoid ( 607584 ) on Sunday July 02, 2006 @02:40AM (#15644838)
      I partially agree with the parent post.

      The last thing you ever want to do when asked by a manager is give a off the cuff answer. It will almost always be wrong.

      So what do I do when I get asked how long something will take? Well, to start off, if I know the code in and out, and I'm aware of the bug, then I can actually estimate what amount of time it will take. If it's not a bug, but something to be developed, and I've done the exact same thing before in my career, I already know the answer.

      If however, neither of these are the case (which is about 98% of the time), I say this: "It'll take me roughly x hours to investigate this matter further and only after that will I be able to give you a timeline that is accurate."

      First off, that gives you way more credibility, and way more leeway. But second, it lets you dive into the situation without having committed your life to fixing it, until you get a better grip on what's going on. If I were for example dealing with a bug on a web app (the kind I regularly work on these days), I would say something like "It'll take me 4 hours to investigate". I will most likely start with about an hour spent understanding the scope and possibly the history of the bug. "Is it reproducible?" is the most important question. If it is intermittent, I will commit to nothing at this point. If I look at the code and can see what is causing the problem, that is, if I can see a clear cause and effect chain that agrees with the test cases etc, I rely on my prior experience and make a guess at how much code needs changing. Plan for it, and plan conservatively. *DON'T* rewrite the application. Only fix the problem.

      If you have time left on your initial x hours, start fixing the problem. See how it goes. Does it look like it's just going to keep on going like this until you fix it, or are you finding your being faced with odd and quirky behaviour left right and center? If you have weird behaviour, beware! If you have undocumented libraries/APIs behaving weirdly, beware! Don't get caught with your pants down. Let your manager know that you are passing some data down to the J2EE/COM/.NET/.Salsa/<NameYourCustomFramework> and that it is not acting as expected.

      For actual development, the process is slightly different. Assess what needs to be done exactly in the same way as above (give an initial x hours to investigate). See what actually needs to be done. *DON'T* rewrite the STL library or .NET framework to do it. Choose the quickest cleanest path with the least amount of development time. Look at all your prior experience: have you previously used STL? Do you know it like the back of your palm? Have you only briefly used COM? And have you had issues with it the times you did use it? Keep that in mind. Try to steer the project in your domain of expertise. Put that as a coefficient in your estimation. If you know you have 100 lines or so of code to write using a library that you know in and out, estimate what you think it will take. If you will have to use a library that you're not really familiar with, pad it like crazy. I mean 2-3-4 times what you expect.

      Those are the practical comments, there's also the more theoretical stuff:

      Don't confuse accuracy and precision. And don't let your managers confuse the two. If I am asked to guestimate a project timeline, saying "4 months, 3 weeks, 2 days, 5 hours, 23 minutes" is more precise but radically less accurate than "4 months". Yeah, it sounds stupid, but accuracy != precision. Don't forget that. Tattoo it on your hand if you must. The longer a duration, the less precise it should be. Commiting to February 5th is ok if you are in January, it is not ok if you are in August. If you are in august, you must commit to a month coming up, and warn your managers to give it leeway. Just cause you said "it'll be done in february", doesn't mean they should plan a launch on February 18th.

      The other thing is a little concept that I really like in comp sci algorithmics: divide and conqu

    • To some extent this may apply to the R&D market, but, enlightened as this may sound, don't expect to win any production contracts without estimates. Remember, a software application represents nothing more than an automated part of a larger process (the notaable exception being entertainment software).

      Once business identifies the need to implement a particular process, it generally does so in recognition of a strategic goal. By definition, any cohesive strategy requires coordination at the organizationa
      • Re:DON'T DO IT! (Score:5, Insightful)

        by MarkusQ ( 450076 ) on Sunday July 02, 2006 @11:11AM (#15645813) Journal

        You are completely missing the point here. It is precisely because it is important that you should not fall into the trap of lying to people. Instead, you should do what any other responsible R&D team would do--decouple the processes of R, D, and whatever comes after.

        Here's how it works:

        • You don't give timelines, ever.
        • At any given moment you provide your customers/management with a set of "current best versions," (all this can be automated) tagged with
          • A unique identifier
          • Everything needed to reproduce that version (e.g. an SVN #, or equivalent)
          • Everything needed to take that version and make it a release
          • A complete, up to date, prioritized, searchable list of the known bugs, features, missing features, etc. of that version, along with the consequences and information about other versions in which those are fixed
          • Tools to upgrade/downgrade from other versions
        • You have your team focus on addressing the highest priority open issues at each moment
        • You work with the customer/management to help them make informed decisions about which version to use whenever they need to ship/install something.

        The point is, because it's important, don't let it become an all or nothing proposition. Make sure that, on whatever date they need to, they have something to run with, and it is as close as you can come to the best possible version that could be produced by that date.

        And it will likely be better than it otherwise would have been, because you can apply all the time you would have wasted defining and defending schedules to actually keep the project moving forwards.


        • To say "You have your team focus on addressing the highest priority open issues at each moment" is to focus on baseline enhancements to the exclusion of strategic application development.

          Now, I thought the OP had a question of project estimation theory. If baseline enhancements are really the topic of discussion here, then you are right, I am missing the point completely. Somehow, I suspect SubliminalVortex's question is larger than that however.
          • To say "You have your team focus on addressing the highest priority open issues at each moment" is to focus on baseline enhancements to the exclusion of strategic application development.

            How in the heck do you conclude that? Or, to put a finer point on it, what does it actually mean? Other than just artificially defining the terms ("highest priority open issues," "baseline enhancements" and "strategic application development") to support your conclusion, can you actually give a cogent defense of this cla

            • How in the heck do you conclude that?

              " issues at each moment" implies a baseline issue tracking mechanism in which end-user feedback is logged, collated, prioritized, and assigned. Am I being unreasonable?

              Or, to put a finer point on it, what does it actually mean? Other than just artificially defining the terms ("highest priority open issues," "baseline enhancements" and "strategic application development") to support your conclusion.... is it just buzzword stew?

              I merely express

    • If they ask for a time estimate, tell them it will be done when they're happy with the result, and don't want anything more, or they're unhappy with the rate of progress, and call the whole thing off.

      I agree that incremental development is the right approach, but you can marry incremental estimation with that.

      It turns out that programmers are good at relative estimation of small features, although they're very bad at absolute estimation of big features. The solution is to
      1. break the project down into very s
  • by QuantumG ( 50515 ) <> on Sunday July 02, 2006 @03:09AM (#15644896) Homepage Journal
    Go read The Personal Software Process []. It's full of helpful, common sense suggestions that every programmer should know. Then go read The Team Software Process, which is a simple forward thinking way of getting programmers to work well together in teams. Then get really really depressed because no matter how hard you try at stuff like this, the software industry is so random and unpredictable that common sense is not all that common.
  • by meburke ( 736645 ) on Sunday July 02, 2006 @03:54AM (#15644984)
    It is nearly impossible to predict the actual delivery time for a programming project because there are too many dependent variables. (For a good pciture of the problems caused by independent variables, read Gordratt's books, "The Goal", "It's Not Luck" and "Critical Chain". "Critical Chain" leads you to the best insights for your position, but the other books are essential prep.) []

    There are two keys to delivering almost always on time; Planning and Management.

    Planning means thinking the project through in the best detail before you start coding. Agile programming seems to work in short, quick-and-dirty projects, but my experience is that it falls short if the project is large and complex. The less decisons you have to make in the middle of the project, and the less changes you have to make as a result, means that the work can me seen to progress along the planned path.

    Management means controlling the variables, and that's where the techniques in "Critical Chain" shine. Nothing, absolutely nothing, is allowed to delay the critical chain in the plan. The biggest dividends come from two parctices: Continuity and Resource management.

    It used to be that if I had a week to do a job that I knew I could do in a day or two, I'd do whatever else needed doing and start two days before the task was due. Of course, If something came up, (essential co-worker gets sick, computer crash, virus, software needs updates, whatever) then I might be delayed during that two days and the task is delivered late. If the task was on the critical path, then the whole project becomes late. The first 10% delay on a project typically costs 25% of the profitability, the next 10% late costs 20%, so being only 20% late can cost 45% of the profitability. People tend to think that if they have some slack, they can relax. Then they wonder why they are late. They should work as if there was no slack! Relax at the END, not during.

    In a large project with multiple developers, some of them may be required to cordinate along different paths, not just the critical path. This is why Godratta called it the "Critical CHain". Those resources MUST be focussed on keeping the essential workflow from bogging down anywhere that may delay the longest chain of dependencies.

    This idea came out years ago, and I've been following project management ever since the 60's. This is the first big change I've seen since 1969. Everyone who told me they tried the Critical Chain method and it didn't work, didn't follow the process. Siemens practically took the whole market for 7200 rpm hard drives by developing them first using the Critical Chain method.

    Good luck on your projects.
  • * Break all down the requirements into the smallest steps you can
    * Take a look at the steps and write down your gut feel on how long it will take on a system that you wrote and know well^
    * Double it
    * Double it again if you are not familiar with the system
    * Add 50% if it is in a language you are not familiar with
    * Add 50% if the code is Convoluted, Uncommented or generally WTF
    * Add 5 hours for compiling/deployment/support

    This is certainly worst case estimates, so tell your customer that, but better to come i
  • This is what I do... (Score:2, Informative)

    by voxel ( 70407 )
    When I can't reach a 80% to 90% confidence level that I can give an accurate estimate I do something different.

    I don't give an estimate how long it will take to develop said feature. Instead, I give an estimate as to how long it will take for me the give the accurate estimate.

    So, for example, I will say, I need 3 days to write some test-code, do some reverse engineering, and try to get part of the feature in, and in that time I am 90% confident that I will be able to give an accurate estimate then how long
  • by dpbsmith ( 263124 ) on Sunday July 02, 2006 @06:39AM (#15645249) Homepage
    The reason why trying to estimate times is a useless exercise is that you can only get a reasonable exercise if you can break the problem down into tasks that resemble similar tasks that have been done before.

    But... ever since the days in the 1950s when the subroutine was first invented, there never should be such a thing as a "similar task." Anything that was done before should have been packaged as a subroutine. Or a reusable object. Or a programming system (entire library or language) designed to attack that class of task.

    Managers that prize predictability over productivity assign their people to do trivial variations of the same work over and over again and get a predictable straight-line curve of time versus work accomplished.

    Good managers allow their people to invest time into tools and techniques are new, hence risky, but pay off with a multiplier effect when they work. They get an unpredictable but exponential progress curve.

    (Bad managers, of course, won't accept the notion that a new task should be estimated at the time that a similar task did in the past. They insist that the task should be estimated as if everything were going to go perfectly this time, no missteps, no problems. ("It will take about a year." "Why do you say that?" "Because, remember, the last time we developed the frammis for the foithboinder project, it took a year" "Yes, but a lot of things went wrong. We had several false starts, because the original spec we were given was wrong. And Jim left halfway through the project and it took a while for Kathy up to speed. And we lost a month when we changed over to the new source code control system." "And why do you think nothing will go wrong this time?")
    • Question #1 "Given a description of a project and its initial business requirements determine whether the project when started, ever halts (completes). The alternative is that it runs forever without halting."

      Question #2 For a project that has been determined in advance to halt, determine also how long it will run before halting without actually starting it.

      Question #3? Ah for this "bonus" question you're supposed to provide the estimate first before you see the question. Otherwise no bonus for you... ;)

  • by namekuseijin ( 604504 ) on Sunday July 02, 2006 @07:00AM (#15645276)
    first one, of course, is: "How can i make a woman tick?"

    i just don't devote any more time to these 2 questions anymore...
  • I have a rule of thumb for database applications that seems to work: Count the number of tables involved and multiply with 3 is it is within a known problem domain, and multiply with 5 if it is not. The the reason behind this, is that each table require a definition (1 day), an input form (1 day), a report form (1 day), testing (1 day), documentation (1 day). Definition and documentation can more or less be left out if you're in a known problem domain.

    Then, if you wan't to give the estimate in calender time
  • I've read two really good items on the subject of estimating software schedules. The first is Painless Software Schedules [] by Joel Spolsky, the Joel in Joel on Software. It's a quick read, and a lot of the comments here are giving the same advice all spread out. Even more useful is Waltzing With Bears [] by Tom DeMarco (ISBN 0932633609) (very talented author, I strongly recommend Peopleware [] to everyone), which is about managing risk on software projects, especially as it relates to time. This is one of the
  • by clambake ( 37702 ) on Sunday July 02, 2006 @11:37AM (#15645894) Homepage
    I once worked for an "XP" (extreme programming, not windows) shop. We had not a single line of documentation in our entire codebase. What we did have, however, was 100% test coverage (at the unit tests level, the functional test levele, and even at the customer-test level). We could estimate, as a team, the length of time it would take to implement every feature in a major product change up to six months out, and hit them all on the exact day we had said we would.

    It could have been the whole XP process or whatever, but personally I believe it was the testing that allowed us to estimate so well. When something is so well tested, and when you are working from a "test-first" mentality, you get the ability to estimate what you think it will be without having to fudge-factor the results. You do this for a while and you find that your gut instinct gets better and better.
  • As developers, we always have a tendency to think in terms of best case scenario. And once you voice that best case once, it gets very difficult to get out of a crazy commitment.

    So *before* providing any numbers, make sure to list the assumptions that you are making, and the interferences and risks that may (and most likely will) occur:
    - other projects and assignments that will steal time and resources
    - spec changes and debugging time, customer interaction
    Explain that you have an estimate in
  • I wrote a tool called Mr Schedule [] that's based on the Painless Software Schedules [] technique described Joel Spolsky. I've found the technique works very well.


  • by josepha48 ( 13953 ) on Sunday July 02, 2006 @02:05PM (#15646410) Journal
    This really depends on lots of things, like, are you familiar with the programming language. Is the existing code something that can find your way around. How well do YOU 'read code'. Yes, 'read code'. I can usually read code like I read a book and get an understanding from it, but only if I am familiar with the language. It also helps if you are familiar with the business logic that you are dealing with, if there is any. Also are you creating new code or working with existing code.

    Creating new code is usually easier to estimate, because once you understand the business rules, you should be able to code it and estimate your time.

    Bug fixes, on ANY code ( don't care who wrote it ) can be trickey. It can often be a situation that if you fix one thing your break something else.

    There is no real set formula I use, but if I think it will take 3 weeks, I'll say 6. I always double my estimate, and often 'fish' for scope.

    Lastly there is nothing wrong with saying 'I'll have to look into that to give you a more accurate estimate. You should be able to take a day or two to get into the code and look at it and figure out enough about it to get an estimate of what is involved. We do this and we call them ballparks. Our ballparks tell how much time the developer needs + qa + spec + IT time + some other things in there. It is usually an estimate.

    Then we write a spec, and in the spec we uncover more. Depending on the outcome of the spec and what needs to be added or dropped the bid can change. Also in the spec we identify ALL the programs that need to be changed. These are things that should have been looked at in the ballpark to give you a better idea of what to extimate.

    It sounds to me like you are a junior programmer. This has nothing to do with your coding skills and everything to do with your project skills. There are many people who can code circles around me, but they can't always give estimates that are as right on as me. As such, take a look at your code. This should be done in a day no longer. Figure out how much time you think you need to spend on it. Multiply by 3.

    After you do this a few times you can start to see how good you are at estimating time. If you estimate time and you are behind on the project, then next time multiply by 4. If you end up ahead of schedule multiply by 2. After a few projects you will be able to say without a doubt exactly how long it will take. Unfortunately some projects will be a range not an exact date, like it will take 6 to 12 months, depending on scope changes.

    really though it takes practice to estimate time. Knowing your own skill level, your knowledge of the language and code base, and what other things will always popup, and lastly your interpution level.

    I'm sadly the goto guy at my company, so my interruption level is high.

  • Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of []
  • by Michael Snoswell ( 3461 ) on Monday July 03, 2006 @01:41AM (#15648429) Journal
    For small changes you can generally guesstimate from exerience with that system. If you know the code well there's a better chance of being accurate. If you have to wade through someone else's code you don't know then be very generous (generally double your guess).

    With all but the most trivial changes you need something in writing to confirm what is wanted - even just an email to restate what you talked about and put your estimate in writing. Get in the habit of this. You can talk about it then look at the code for 30minutes and make a far better estimate than being pressuried into giving an answer straight away.

    On much larger projects the time spent on actual coding gets less and less and the time spend on specifications, prototypes, testing, documenting, reviewing etc gets much bigger. I recently worked on a $250m sw project where coding was about 20-25% of the time. It depends on what the code is for. Normally coding is about 40% of a project but the more critical a system the less time spent on code and the more spent on design and testing. I've worked on some safety critical systems (ie where someone dies if your code is wrong) and coding was about 10% of the project. This might take a lot of joy out of being a programmer but it pays to get it right!
  • Old Boss's Forumla (Score:3, Insightful)

    by Teancum ( 67324 ) <[ten.orezten] [ta] [gninroh_trebor]> on Wednesday July 05, 2006 @12:20PM (#15660659) Homepage Journal
    My old software manager came up with an outstanding way of trying to estimate project completion for trying to tell upper management when something would be done.

    He asked each of the software engineers how long it would take, based on their "gut" instincts.

    Then he multiplied the figure by two and moved it to the next higher order of time. I.E. weeks become months, months become years. One time he asked us to estimate when we could get something accomplished and we told him two years. He cried for a little bit and went to upper management and said "Never, we can't get that done".

    Surprisingly this turned out to be a very effective way for him to gague when things would actually get accomplished, and more often than not he was dead on correct. He also didn't let me in on his secret until just before he quit, but it has also helped me to make my own estimates for customers when I'm doing contract work now. I do the same thing where I make a preliminary estimate based on known issues and then apply the above rule to my own guess. I have (fortunately) been fairly accurate with my guesses at that point, even if it makes the customer angry with them insisting that it must be done in a shorter period of time.

Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.