Please create an account to participate in the Slashdot moderation system


Forgot your password?
Software Operating Systems Technology

Ask Slashdot: Are Accurate Software Development Time Predictions a Myth? ( 222

New submitter DuroSoft writes: For myself and the vast majority of people I have talked to, this is the case. Any attempts we make to estimate the amount of time software development tasks will take inevitably end in folly. Do you find you can make accurate estimates, or is it really the case, as the author, DuroSoft Technologies' CTO/Co-CEO Sam Johnson, suggests via Hacker Noon, that "writing and maintaining code can be seen as a fundamentally chaotic activity, subject to sudden, unpredictable gotchas that take up an inordinate amount of time" and that therefore attempting to make predictions in the first place is itself a waste of our valuable time?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Are Accurate Software Development Time Predictions a Myth?

Comments Filter:
  • Yes, but... (Score:3, Insightful)

    by Anonymous Coward on Wednesday April 26, 2017 @07:22PM (#54309441)

    Try getting a contract awarded with "It's too chaotic to tell"

    • More often than not, specifications are general enough that you may as well be telling someone "I once saw a car driving down the road, and this is what I remember about it... build me one!" Where it's unknown what pieces you already have at your disposal, what parts need to be adapted, and what needs to be fabricated from the ground up.

      With clear, unchanging specifications on what is being built, than sane timelines can be given. When it's "smile and figure it out", than the timeline too is variable co
      • Consider a request for a table interface with which to enter some data, enforce some rules, and print some reports.

        Automated tools can build that in seconds. A few hours of tweaking and you're done.

        Now write the Obamacare website. Wait. That site was entirely data driven and should have never been as convoluted or complicated as it was. Of course the developers were probably getting updated requirements every week right up to the roll out date. THAT is why software estimates are off by so much sometimes.

    • If software development was "chaotic", then it would be overestimated as often as underestimated. But that isn't true. Overruns are way more common.

      Here's a way to get better estimates: Instead of asking Bob "How long will it take for you to complete this?", ask Fred "How long will it take Bob to complete this?". By asking a 3rd party, you take away the hubris factor.

      • Re: (Score:3, Informative)

        by bored ( 40072 )

        That doesn't work either, unless Bob is familiar with all the details of what need to be done, in which case your just as likely for it to be a "how long bob thinks it will take him" kind of answer.

        I have literally seen estimates of "two days" to write a firmware device driver for a network card from a manager that regularly wrote code. In the end the guy that ended up doing it spent close to a year before it reached the level of "just works"

        • Re:Yes, but... (Score:5, Insightful)

          by Dutch Gun ( 899105 ) on Thursday April 27, 2017 @02:25AM (#54311079)

          The problem with software development is that unless you've done that exact same task before, you really have no idea what's involved. And if you HAD done that exact task before, you wouldn't need to be doing it again, as you could re-use most of your previous work. Unlike with, say, constructing a building, once software is well-built once, it doesn't have to be built a second time, at least within the same company, or if its open source.

          Management is also to blame on occasion. I put together a schedule for a videogame project for a major publisher, and the schedule was rejected, saying it wasn't detailed enough. They wanted finer-grained breakdowns of tasks, so instead of one to two week tasks, they wanted one or two day tasks. The only problem: the game wasn't even designed yet - only a rough idea of the genre and licensed property we were using. So, someone (not me, thankfully) dutifully put together a bullshit schedule with fine-grained bullshit tasks, and as the due dates arrived, we simply checked off those tasks in our official project management software.

          In the meantime, we had our own spreadsheet with our real tasks and timelines that we used internally, although we tried to match up major milestones as best we could. Since it was a hard deadline, we finished the core game systems as soon as possible, ruthlessly cut extraneous features, and still delivered on time. I'm sure the publisher's producers still think it was their detailed scheduling that kept everything on track.

          • Re:Yes, but... (Score:5, Insightful)

            by utahjazz ( 177190 ) on Thursday April 27, 2017 @10:26AM (#54312621)

            This is exactly right. Unfortunately so many people think that constructing a building is a good analogy for "constructing" software, and think the same methods and ability to schedule in detail apply. It's the worst analogy. A better one is, making a schedule for the invention of a flying car. You know exactly what you want it to do, but you don't know how you'll make it happen yet, and you certainly don't know the exact date when you'll have it all figured out.

        • The asymmetry of mis-estimation is partly explained by a sort of optimism.

          Our instinct is to plan for no obstacles/distractions/complications, where in reality it's rare for work to proceed in this way.

          Another cause is that (as Dutch Gun points out) often in software development, you've never done a task quite like that before, so you can't draw directly from past experience.

          • Re:Yes, but... (Score:5, Informative)

            by computational super ( 740265 ) on Thursday April 27, 2017 @10:51AM (#54312809)

            partly explained by a sort of optimism.

            Well, maybe a little, but I think it has more to do with every request for an estimate being something along the lines of, "I'm not really sure what I want, and I need you to estimate it, but the budget only allows for two weeks, so you should probably not say anything more than two weeks." When we're young, this freaks us out, and we try to talk them back from the brink of insanity and get them to see that this is definitely more complicated than two weeks, but they beg, bully and cajole until you break down and agree, certain that you're going to be fired (from your first job!) after just two piddling weeks. So you put together what you can, it doesn't work, two weeks pass, you keep working, nobody fires you, nobody even notices that you slipped the estimate. You keep working on it, the boss keeps asking "is it done yet", you get really good at apologizing and explaining that the network didn't work the way you thought and the new version of the database is different than the old version in undocumented ways, and a few more weeks pass and you get something working, and they say it's shit, and you go back and make a bunch of modifications and they keep asking is it done yet and you keep apologizing, and three months later you actually have a decent working product, and nobody fired you, and the company didn't go out of business because you blew your estimate by a factor of 6 and everybody actually seems reasonably happy.

            And then they come you and say "I'm not really sure what I want, and I need you to estimate it, but the budget only allows for two weeks, so you should probably not say anything more than two weeks." And you start to protest, but then you remember last time, so you say, "yeah, sure, two weeks, whatever dude," knowing that it doesn't matter and gradually coming to the realization that you're just playing a game whose rules aren't written down anywhere, pretending that you can deliver anything in two weeks, knowing that they know you can't, but both of you are playing a game of chicken at the end of which nothing happens.

            And then after lather-rinse-repeat for 30 years, you go on to slashdot and you tell the young kids, "just give them the number they want to hear, nobody takes estimates seriously anyway" and some loudmouth PHB who figured out how to turn on his computer replies back "they're going to offshore all of you if you don't start producing accurate estimates because there are real-world consequences for missing dates" and you shrug your shoulders and go back to work because you know that the offshore people can't estimate any better than you can and the only people who insist that software estimation is realistic are the people who wish it was realistic, not the ones actually expected to produce it.

      • "Here's a way to get better estimates: Instead of asking Bob "How long will it take for you to complete this?", ask Fred "How long will it take Bob to complete this?". By asking a 3rd party, you take away the hubris factor."

        That *is* exactly how it's done, which is proof it doesn't work either.

        Usually the estimate doesn't come from asking Bob how long it will take to him, but some third party (a sales manager, Bob's technical manager...).

      • How do you know overruns are way more common? Your sample set consists of two sources of samples: personal experience (and you might just be a bad planner), and events reported in the press (and 'project finishes on time, on budget!' usually doesn't get reported).

        I'd like to see some numbers before I believe that statement.

      • It isn't hubris.

        I can estimate fairly accurately. But Management/user grimaces and says "It can't take that long, All You Have To Do Is..." and forces me to chop it in half.

        Then when it takes twice as long as the accepted estimate, it's My Fault.

        I allow a fudge factor in my estimates. Even the simplest projects almost invariably develop complications. Plus I know that a good deal of my time is going to be spent in one small module finding that misplaced comma.

      • by Aaden42 ( 198257 )

        If the chaos resulted in reduced scope about as often as it resulted in increased scope, then you might well see symmetry in the over-/under-run of estimates. It's far more common for new features or unforeseen requirements to be added to the scope of work than for anything to be removed.

        There's chaos in the development process itself that results in some things taking longer or shorter than initially expected. The external chaos of shifting requirements turns what happens during development itself into a

    • Try getting a contract awarded with "It's too chaotic to tell"

      The other key component of a contract is defining a budget, which gets blown when timelines inevitably become "chaotic".

      Perhaps the real myth that is being identified here is defining an accurate budget for software development.

  • by Anonymous Coward on Wednesday April 26, 2017 @07:25PM (#54309457)

    Take your developer's estimate
    Increase that by 40%
    Double that

    It seems incredibly arbitrary, but I have learned that the 40% covers testing and implementation, while doubling the entire amount allows for the customer seeing the first result and _then_ telling you what they really want.

    Try it, you'll like it

    • That's similar to what I've experienced and seen reported in studies. When I say "10 hours", that really means "10 times X hours", but that X factor is relatively consistent. Each of my teammates are similar - they are always wrong, but normally by the same multiplier each time.

      Developers tend to be reasonably good at estimating the RELATIVE amount of work, they can say "job A will probably take twice as long as job B". This assumes the work is broken down into pieces small enough to estimate. What they ten

      • by vlad30 ( 44644 ) on Wednesday April 26, 2017 @09:00PM (#54310007)
        Developer’s and programmers have relatively poor time estimation skills. The one thing that makes them good is focus and getting lost in a problem often getting lost in the work and waking from this extreme concentration days later not realising how much time has passed and only counting the final Eureka moment where the programming was quick. Then when asked next time for a expected time they estimate the perceived time of hours not days or weeks.
    • That's pretty close to what I've found too.
      Something that will take 2 days really takes a week. (2.5)
      Something that will take 2 weeks really takes a month. (Also 2.5)
      Even short projects seem to fit this 2.5 number where something that is suppose to take 2 hours generally takes half a day.
      The job itself actually only takes 2 hours but the debugging, testing, feature creep, and making it live always seems to more than double the time.

    • by Anonymous Coward on Wednesday April 26, 2017 @08:31PM (#54309877)

      Take your developer's estimate
      Increase that by 40%
      Double that

      It seems incredibly arbitrary, but I have learned that the 40% covers testing and implementation, while doubling the entire amount allows for the customer seeing the first result and _then_ telling you what they really want.

      Try it, you'll like it

      HA. You have no experience in management obviously. Here's how I do it:

      Take the developer's estimate
      Tell them it's too long
      Halve it
      Tell the customer
      Project gets behind
      Start the death march (60+ hours for everyone but management, we have families!)
      Project gets behinder
      Customer is pissed, but doesn't really have any other options
      Project comes out OK, but is much later than even the original estimate that was halved
      Customer is happy, management is happy, engineers are disposable
      Go to Hawaii with my bonus!

      • This was modded "funny"; should be modded "cynical but true"; all the contractors around these days seem to use some variant of this technique.

        All of them. Onshore, Offshore, the lot.

    • I use "double it and add 30".

      The nice thing about this rule of thumb is it also works pretty good for converting Celsius to Fahrenheit.

    • My company does something similar.

      Basically just triple whatever estimate we come up with.

      This comes with a huge benefit: If it turns out we over-estimate, the client is happier with an earlier finish date, or we can put a little extra time/effort into something that just didn't feel as polished, and the client got an even better value for their money.

      We also have a policy to not bill over our quotes, so over-estimating is crucial. It holds us accountable so we don't bleed our clients and create bad blood.

      • My company does something similar.

        Basically just triple whatever estimate we come up with.

        This is basically what we do too. The problem I see with this approach is it prevents you from getting better
        at estimating. If you as a developer triple your estimate to compensate and the manager then triples that
        number, the number is artificially tripled twice. I've tried slowly increasing my estimates so that they are more
        accurate but then people balk because when they take my more realistic number and triple it, it looks to be
        too much compared to previous projects even though everyone knows the previ

    • Weird thing is, everyone's estimate is off by a factor of roughly X, but the value of X changes from person to person. The key is to figure out what your own personal X is and start using it.

      If you're the kind of person who is consistently late, then your manager already does this without telling you.
    • while doubling the entire amount allows for the customer seeing the first result and _then_ telling you what they really want.

      You are handling scope creep wrong. Agree the scope then estimate and charge appropriately if they wan't to change the scope you re-estimate (Including for backtracking and scraping existing work that has already been done) and then charge them again.

      Rince and repeat

  • by SuperKendall ( 25149 ) on Wednesday April 26, 2017 @07:34PM (#54309525)

    Even with known and well understood languages/technologies/frameworks, you can and will run into glitches that can take days to complete something that was supposed to take hours - or even longer if the developers are not skilled in debugging and isolating problems!

    StackOverflow has helped the industry in this regard, because now a lot of times you can reduce some mysterious problem to a fifteen second StackOverflow search which instantly answers the issue. But not always, and there are always issues when actually programming any design that you can uncover hidden flaws and need to correct them.

    What I would love to see is some kind of approach that instead of a time estimate, gave a time along with a percentage of confidence. Two different tasks may seem to take about five hours, with one you are 90% sure it can be done in five hours, with another (like brand new code) it can be more of a 50% five hours. Then you could use this percentage to determine the actual areas of coding likely to cause schedule issues and monitor them more closely. The other nice benefit of this approach is that it factors in the actual developer understanding and abilities more than just a straight hour estimate. Maybe you even put a cap on how high a confidence level a developer is allowed to give until they have met given estimates a number of times already...

    Coding is a chaotic system, yes, but it's not like it's fully chaotic, and there are patterns within the chaos I think you could determine over time.

    • by networkBoy ( 774728 ) on Wednesday April 26, 2017 @07:58PM (#54309679) Journal

      I always provide my managers with confidence interval estimated times
      50% 10 days (assumes *nothing* goes wrong, no interruptions, and high code reuse)
      90% 15 days (assumes no catastrophic issues, no interruptions > 2 hours and only 5 of them, moderate code reuse)
      100% 55 days (the wheels fell off, severe schedule impacts of interruptions non stop, no code reuse)

      My boss laughed at my 100% estimate until it actually happened.
      A lead dev (who could be counted on for sound advice delivered in a belittling way) was struck down by lung cancer and ceased to exist. Another lead dev who was even brighter, and much nicer to work with was poached by a competitor, both within days of each other. The code was cutting all new territory in the system, so maybe 15% reuse? *and* some panicky manager started having $deity damned _daily_ meetings about it.

      We almost missed my 100% date, made it by about 16 hours.

      • I always provide my managers with confidence interval estimated times

        That is a great idea - I did the same thing years ago at a past employer - sadly the manager knew not what to make of it, so I only did it once. It was more accurate than the "real" numbers then ended up going with.

        But I think giving a range of timeframes with percentages is probably the best way to go, if you have to give estimates at all...

      • by Kjella ( 173770 )

        *and* some panicky manager started having $deity damned _daily_ meetings about it.

        This is my favorite bit when something very unexpected happens and managers make us twice as late by creating a ton of overhead about when/how/why/re-estimating/re-planning and plain old nagging to get it fixed. If what you care about is getting it actually done, let me work. If you need an alternative other than not delivering I can help you find that, but other than that you're not helping. You're slowing us down. This is particular frustrating when you're not 100% assigned to a project, yeah I'm supposed

      • That's a good method; unlike simply overestimating the task, it allows you to build in some contingency while still start out with a planning that follows the most optimistic path. Hope for the best and plan for the best. Because another truism of software development is that any overestimated task will stretch to fill the allotted time.
  • by CAOgdin ( 984672 ) on Wednesday April 26, 2017 @07:38PM (#54309559)

    ...estimates of resource requirements (including time and budget) for software projects.

    However, making estimates of Resource Requirements that will be acceptable to Management...that's impossible. It's amazing how so many people who've never tried can make such ignorant demands...and think they're being "fair."

    I've done many project plans for clients, and when I give them the results, they always bitch. But, when the project is actually delivered, they finally agree that I was right in the first place. After that, it gets easier...which THOSE clients.

    Fortunately, I'm now retired, and no longer have to suffer these dolts. And, MY projects are quickies that work within a few days, and I love to tenderly "evolve them" over multiple successive iterations, adding new features as I go. My latest one is about 15 generations into development, and I may bring it to market if I can find a suitable partner. It's a novel approach to easily-recovered 100% daily computer backups. it's a much more practical methodology that doesn't require prescience before the first build is done to know every detail about the final naturally evolves.

    • I've done many project plans for clients, and when I give them the results, they always bitch.

      Oh man this 1000 times, but in my case it usually tends to be management that does this. They ask for an estimate for something, you tell them 100 hours, they say that's crazy and change it to 40. Then when you end up getting it done in 80 (which is better than the original estimate), they complain about it taking twice as long as it what they budgeted. This appears to be pretty common, it's not just a single organization I've been at that is guilty of this (of course someone on here will say maybe the p

      • by scdeimos ( 632778 ) on Wednesday April 26, 2017 @08:22PM (#54309831)

        Yes, this. Good management knows that you know your trade and accepts your estimates. Bad management thinks they know better and try to negotiate on estimates.

        Over the years I've found that feature development, particularly adding to existing systems, will get better estimates if we're allowed a spike to review the affected areas up front - this is when you discover unexpected dependencies or just sheer awful spaghetti. When you're not allowed to do this up front is when you come across the unexpected gotchas that blow out the best estimate you could provide at the time.

      • by vlad30 ( 44644 )
        A sign seen in some work practices Speed, Quality, Low Price you can only have 2, choose wisely.

        Yes when clients and managers choose often it speed and low price in the preparation then demand quality at which point the speed disappears. to maintain the price which rises anyway due to the extra time cost but this isn't passed on leading to failure.

      • I run into the same problem. The funny thing is my manager knows my estimates are off. My manager told me once that when I give him an estimate, he takes it and multiplies it by 2.5 so a 2 day projects becomes one week and a one week project becomes one month. The problem with this is if I give him a realistic estimate, he multiplies it by 2.5 and balks so I'm stuck basically giving him low ball estimates with us both knowing it will really take 2.5 times longer. So in a weird way, My estimate is actual

    • by Tablizer ( 95088 )

      I've done many project plans for clients, and when I give them the results, they always bitch. But, when the project is actually delivered, they finally agree that I was right in the first place. After that, it gets easier...[with] THOSE clients.

      Indeed. Many PHB's have to learn the hard way:

      "Who knew healthcare would be so difficult?"

  • by bobbied ( 2522392 ) on Wednesday April 26, 2017 @07:43PM (#54309585)

    Like any "process" you can do better but a couple of things have to be true...

    1. You had better KNOW what your development process IS (not what you document, or what you want but what it actually IS). Until you know how you develop, test and deliver software from start to end, there is no way you can estimate how long it will take accurately.

    2. You need to develop a method of coming up with your educated guesses that is repeatable. The process must allow you to estimate every step of your development process and how much each step is estimated to cost both in time, materials and labor.

    3. You MUST collect metrics that allow you to track actuals to estimate for each individual step in your development process though how ever far you get (hopefully to completion).

    4. Next time you get a contract proposal and you start though this process again, when you get to step 2, do your estimates, but then compare past projects data from step 3 and see if you need to add or subtract some fudge factors based on past history. Rinse Lather and repeat.

    Eventually, you will get better at the estimation and have more confidence in your ability to bid contracts....

    • by kelv ( 305876 )

      2. You need to develop a method of coming up with your educated guesses that is repeatable. The process must allow you to estimate every step of your development process and how much each step is estimated to cost both in time, materials and labor.

      I was always taught to estimate HOW you are going to do something, not WHAT you are going to build. If you start with a block diagram with 8 blocks and your work breakdown structure has 8 major headings you are probably going to get rubbish estimates. Building those 8 blocks and connecting them up probably involves 20 macro-level steps. Many of the developers I've seen get this wrong don't think through HOW they will build the final state they are trying to get to so their estimates miss a lot of stuff.

      • Good point...

        In my 25 years of doing this, I can tell you that the most often used way to estimate a project basically boils down to "How much can we get the customer to pay?" Time and time again I've sat though meetings where the sales person kept saying "we won't ever win the contract with that bid" followed by an order from the executives to bid lower. One time the executives took our estimate, subtracted 2/3rds of it and submitted that as the bid over our objections. We won and I quit as soon as I c

  • Yes.

    The title is one of the few instances where Betteridge [] is wrong.

  • by gravewax ( 4772409 ) on Wednesday April 26, 2017 @07:48PM (#54309629)
    Quality of prediction comes down to quality of the information fed into making the prediction. Given all information up front with good BA work up front and requirements and scope that don't change I can generally provide good predictions that are close or that even come in under budget for our projects (good predictions always have some buffer built in for staff and technical problems).
  • by mschaffer ( 97223 ) on Wednesday April 26, 2017 @07:50PM (#54309643)

    Until an even somewhat accurate time is reflected in with the estimated time remaining progress bars there can be no hope for predictions of software development times.

  • by w3woody ( 44457 ) on Wednesday April 26, 2017 @07:55PM (#54309661) Homepage

    I'm able to estimate fairly well how long something will take for me, but with a bunch of proviso.

    • The code I'm asked to modify is written in more or less a sane way.
    • The specifications are relatively complete.
    • The interfaces are relatively "orthogonal"; meaning things are relatively consistent from page to page.
    • The specifications are not subject to random changes by project management, by product managers, by business people, by the CEO or his brother Bob, or at the whims of some QA person who can't read a specification.

    Sadly most projects fail one or more of the points above--which make most estimates absolutely worthless.

  • by AnotherBlackHat ( 265897 ) on Wednesday April 26, 2017 @07:57PM (#54309673) Homepage

    Performance predictions have an optimistic bias.
    It's known as the planning fallacy []
    It amazes me how people who should really know better fall for this.
    For example, if the last time you did it, it took 3 weeks, a good prediction is that this time it's going to take 3 weeks.
    Yet most people will predict less than 3 weeks - even if you point out the planning fallacy to them before hand.
    I can almost here the rationalizing; "It's not going to take 3 weeks again, because we aren't going to make the same mistakes again."

    But it's far, far, worse than just an inability to predict accurately.
    Frequently schedules are determined by need rather than reality. As in, we need this done by Tuesday - make the schedule accordingly.

    • by Jeremi ( 14640 )

      For example, if the last time you did it, it took 3 weeks, a good prediction is that this time it's going to take 3 weeks.

      Hopefully it will take less, because this time I will be able to take the code I wrote last time and just re-use it, possible with some minor modifications, rather than designing and implementing it all from scratch.

      (Or if I can't do that, then either it's a new task and there wasn't actually any "last time I did it", or I did a lousy job last time of designing my code to be re-usable. Software development is mainly about automating previously manual processes so they can be repeated more quickly/easily in

  • I write embedded software. I always run into hardware issues, some of which can take weeks to prove it's the hardware, not the software. There's no way to predict that kind of thing.

    My claim to fame was an Intel Ethernet chip that came out in 90/91. It had a bug, I found a workaround. I sent a bug report to Intel, it was in errata for the chip. 3-4 years later I was introduced to Linux. Out of curiousity I looked into the driver for this chip, they had my workaround line for line.

    The problem? Y
  • Estimate 4 weeks for the job. Then:

    Finish in 3 weeks: "it was an easy project after all! Your estimate cheated us"

    Finish in 5 weeks: "you're a crappy engineer! you cheated us by pretending you could do the job"

    Finish in 4 weeks: "that's suspicious! you obviously finished early and then goofed off. You cheated us"

    Moral: you can say how many or how long but never both! Or: it'll take between 2 weeks and 2 months, depending.

  • by epine ( 68316 ) on Wednesday April 26, 2017 @08:13PM (#54309775)

    What he wrote:

    UPDATE: as a direct result of "the views espoused in my engineering article on Medium" I have been terminated from my contracting position at my current employer.

    What's he's hoping people read:

    UPDATE: solely as a result of "the views espoused in my engineering article on Medium" I have been terminated from my contracting position at my current employer.

    Unfortunately, version 1.0 typically falls under the thick veil of he said, she said.

    Here's the exact point where he wanders off into the weeds:

    Its intractability comes not from incompetency or from a lack of discipline, ...

    It doesn't take a 4-Sigmund review to spot the out-of-school litigation here. No one in a state of conflict appreciates the lateral spread of subtext.

    I know estimation is often used as a management bully club, and I've had some pretty dark thoughts about some indivisuals who have chosen to behave that way, but sorry, I'm just not feeling the sympathy in this instance.

  • TFA has an update suggesting the author got fired for writing it

    UPDATE: as a direct result of “the views espoused in my engineering article on Medium” I have been terminated from my contracting position at my current employer. Still figuring out what my rights are in this sort of situation so any guidance, advice or employment offers are appreciated. I will be adding a GoFundMe link and a more detailed postmortem shortly.

    • I would've potentially felt some sympathy, but the gofundme part certainly smashed any chances of that. Sad thing is, a highly paid contractor who gets himself terminated from a contract will likely raise 100x more with his gofundme begging than a street bum who actually needs the money will get.

  • Solved problem (Score:5, Informative)

    by Orgasmatron ( 8103 ) on Wednesday April 26, 2017 @08:17PM (#54309795) []

    This is one of his blog posts that is almost an infomercial for his product, but he does describe the concept well enough that you could roll your own if you wanted to.

  • As lead video game tester at Accolade/infogrames/Atari (same company, different owners, multiple personality disorder), I was responsible for getting ten titles through QA. The schedule set by the producer, developer and marketing teams were always based on milestone bonuses. Everyone got a little something extra in their paycheck if the schedule estimate was accurate. As a lead tester I got no bonuses and cared less about anyone else's bonuses. I typically added six weeks (+/- two weeks) to the schedule es
  • Remember Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

  • by Kazoo the Clown ( 644526 ) on Wednesday April 26, 2017 @08:45PM (#54309959)
    The solution is not to *impose* a schedule, but let the developers who are going to do the work make the estimate, and don't argue their estimate down. Others who have suggested multiplying by some factor might be a good idea as well-- but unless the developer has his own credibility on the line for the estimate, he won't put in the extra work to try to make up for a schedule overrun.
    • The problem is not imposing a schedule, although that often happens; it's that the developer is not good at giving an accurate estimate and will tend to underestimate the time required.
  • If the problem is well-defined and the developers have worked on similar projects before, they can probably give fairly accurate estimates on how long it will take. Mostly with mid-sized projects, I've found, because any delay is disproportionately large in a tiny project, and large projects are more likely to have significant managerial interference after the project goals were supposed to be set in stone.

    If you're looking as something novel, then estimating the required time becomes more of a dark art.

    • Exactly. An Android developer might know something is 'easy', but forget that it's only easy due to a new API that came out 3 years ago, but is STILL 1 or 2 versions ahead of the minimum version of Android for which the customer demands compatibility. Sometimes, it might be merely 'hard' to achieve something with an older version (ex: pdf-rendering, which didn't exist as an Android API until Lollipop). In other cases, it might be borderline-impossible to achieve with older versions... for example, low-laten

  • they are.
  • I used Function Point Analysis weighted for web based applications. But this presupposes there will be no major increase in scope, or increase or decrease in staffing. It also worked well when I had close contact with customers and could understand their needs directly.

    In fact as soon as I saw velocity in the Agile, or related, Scientific Software Management practice I immediately "got it". One number to calibrate on to embody a host of factors internal and external and measure complexity.

    The problem comes

  • (I am the OP)
    TLDR: lost my job for writing this article
    you can donate here: []

    While I list my title online as the CTO of DuroSoft Technologies, I am a part-time graduate student, and the vast majority of my income comes from a contracting position I (until just now) held at a popular SaaS company. I am not going to leak the name of this company, and I would politely ask people who reply to this thread not to speculate about about which company this might be, or otherwise
  • MAKE IT HAPPEN signed your PHB.

    Just always promise the world to the client and it will magically get done without input from the team of course.

  • This isn't any thing new. People are bad at estimating how long a task will take, wether it is developing or building a skyscraper. There is a lot of literature on why people are bad at estimating the time it will take to perform a sequence of tasks. Development is simply the next in a long line of activities that people try to estimate, and do badly.
  • I have have pretty good success with this process:

    Tasks: write down all them thar software bits that need to be coded.
    Effort: How much time will each task take.
    Complexity: Complex things take more time - make up a coefficient. GUIs are always complex.
    Risk: How possible is it that something wont work? - another coefficient.

    Now put them all in Excel, and then adjust the complexity and risk coefficients till it matches with how much you want to charge the client.

  • No, but they do come with a "cone of uncertainty" that gets larger the farther into the future you predict.

    Software development predictions also come with a cone of uncertainty. You can predict pretty accurately how much you can get done in the next week or two, but those predictions get less accurate the farther into the future you look.

  • by JBMcB ( 73720 ) on Wednesday April 26, 2017 @11:23PM (#54310587)

    Sure, coding this up should be pretty quick, since I just need to plug A into B using X. .NET does W, Y and Z, so it should do X.

    Me: Wait, where is X?
    Microsoft: X has been deprecated in 64-bit.
    Me: Wait, why? W, Y, and Z all work, why not X?
    Microsoft: Nobody uses it.
    Me: It's listed as a feature in your docs! It's the recommended method! If people are doing W, Y and Z, they are definitely doing X!
    Microsoft: Whoops, wait a sec... There now they say NOT to use X as it's deprecated.
    Me: Fine I'll write a 32-bit shim
    Microsoft: .NET won't allow you to do that with X for security purposes
    Me: Holy cow I need to write a friggin' service and pipe crap to it just to get X to work?
    Microsoft: Or write your own implementation
    Me: The whole point of X is it's a pain in the neck to implement properly and I'd rather be spending time on user-facing stuff, rather than become an expert on X, which I'll only be using for this one particular feature. Fine I'm re-implementing, my original estimate has now increased 10x.

    Six Months Later:
    Microsoft: Good news, X has now been implemented in 64-bit! Download it here...

  • It's impossible to give an accurate time without a nice padding estimate. Well you can get close, you'll never get good enough for it to really matter. When estimating a software project always add an extra 20% on top of the original estimate to get something realistic.
  • Here's how to calculate a 100% accurate estimate 100% of the time, when your manager asks you to predict how long it will take to implement feature X:

    1. Tell your manager you'll get the estimate for them as soon as you've done the necessary research
    2. Go back to your desk
    3. Write down the current time
    4. Implement the feature
    5. Subtract the time you wrote down in step (3) from the current time. This is your 100% accurate estimate of how long it took you to implement the feature
    6. Email your manager, a

  • At one place I was at, a strategy that seemed to work for at least one manager was to keep a spreadsheet, listing each developer. He'd record their estimates, the time it actually took for each task, figure out a multiplier, and apply it to the estimate for the next task. After a while, he had fairly accurate estimates of what each of his developers would take for each task, moreso than most other managers. Granted, it takes time and will be highly variable at first, but *does* seem to zero in after a few d

  • I.e. if you carefully estimated the time, tell them you need twice that. If needed, waste some time to be accurate. Of course, even this method requires a high level of skill, because the average developer (i.e. not really good at anything) will deliver results with even more delay if given more time.

  • This topic comes up pretty regularly, and it always amazes me that there is not an appreciation that nearly everyone in science and engineering has to work through unknowns in development on a schedule, and we've all adapted.

    I work on developing a product that integrates a lot of different fields. I work with various engineers, physicists, biologists, chemists, and programmers. All of them have tasks that are impossible to estimate time and cost for with 100% certainty. That's an unreasonable bar to set.

  • It's amazing how often I've seen projects - even strategic / multi-million buck ones - being planned "on the back of an envelope".
    Some dude shits out a guesstimate that's then slapped in a powerpoint and it becomes the target & budget which is handed to the luckless PM and the dev team.

    Getting the right people involved, and going into detail on scope, spec and architecture etc. is not "wasted time and money" but instead an investment; these are activities that will have to be done (or should be done) ev

  • by MoarSauce123 ( 3641185 ) on Thursday April 27, 2017 @06:26AM (#54311699)
    ....there are no accurate requirements or no requirements at all. If you don't tell devs exactly what to build they have a tough time estimating. Even when there are requirements, if there is nothing comparable done recently it is difficult. Besides that an estimate implies that it is NOT accurate! Anyone who takes estimates as fact is a fool.
  • Take a wild ass guess -- just take your first best guess.

    Then double it, and move to the next larger unit.

    1 hour becomes 2 days.
    1 day becomes 2 weeks
    1 week becomes 2 months, etc.

    You will be surprised how accurate it is. And you will virtually always deliver just a little early.

  • ... the act of planning has value

    in the long tradition of "if there is a question in the /. title - the answer is yes" - yes "accurate" software development time predictions are myths

    of course "accurate time predictions" are going to be "myths" for any massive project (a google search for "defense project over budget" produces interesting results - like this [])

    the fact that people tend to get better at "estimating" anything the more experience they get at "estimating" is a big part of the reason why "lead so

  • The real problem is poorly considered and expressed requirements and the resultant feature creep. This is failure of governance, not a short coming in developers. Those saying I double (or whatever) their programmers estimates need to look in mirror and recognise the failure is their own.

    So no, I do not have any trouble giving accurate estimates, but then I refuse to give any until the requirements are well defined and understood by the team. I my experience this is norm now for most genuinely agile tea

  • I could write a completely accurate time estimate, down to the minute. It would take me three times as long to produce the estimate as it would to just do the work in the first place, but yes, I could produce an estimate of any arbitrary accuracy.
    • And here it is. I was hoping to find someone saying it.

      Back when I was yay tall, I worked for a large web-development company. They'd spend six months to a year to draw-up a spec document that would take us three weeks to build. I quit when I found out that they spent $1.6 million dollars (this was in 1997) on the spec process alone.

      Now I run my own small web development company, doing much larger things than they ever did (right from the start), and with good clients, time estimates are never more than

  • Which people are you talking to?

    I've found that I didn't become great at making estimates until I had been programming for 20 years.

    For years 21-30 I've been great at making estimates.

    If you're working with customers hiring programmers from India with only a few years of programming experience or you're working with companies who practice age discrimination, then you're going to find that nothing ever gets done on time.

    If you're working with experienced programmers, then your experience will be the opposite

  • I have, in my 35 year career as a software engineer, had one time estimation rule-of-thumb that has held up well. Take the best estimated time, double that, and add 10%. Never fails!
  • I've developed reliable dev estimates in the past. This relied on us having a single codebase that we worked consistently on for an extended period. We knew our own infrastructure. We knew what we were doing. If there were major areas of doubt, we used a timebox for investigations.

    The kicker: however long it took us to write the code in the end, it took us one tenth as long to create the estimates.

  • by dpbsmith ( 263124 ) on Thursday April 27, 2017 @10:28PM (#54317183) Homepage

    If you're doing it right, you should never be doing anything twice. Anything you do should become a packaged and re-usable element that doesn't need to be coded again. I don't care whether you call it a subroutine, an object, or what have you.

    Software development, done right, should grow exponentially--with a highly fluctuating exponent. No task should be predictable because no task should closely resemble anything you've done before. If it does, you shouldn't need to develop new code, you should just be able to re-use old code.

    Well, OK, this is a gross oversimplification, but it does capture something fundamental about software development.

    In the past I've found that managers almost prefer to do thing repetitively, over and over, the same stupid way. They love what is conceptually close to a duplication of the essentials of the last job, because although it's highly inefficient, it's also highly predictable. They would much rather have a near-linear curve of accomplishment versus time, then a much faster, but much less predictable exponential-with-fluctuating-exponent curve.

    The typical manager would probably order you to recode the same thing ten times rather than "waste time" writing a subroutine.

    (To be fair--it's hard to write a truly re-usable piece of code and easy to waste time in the name of re-usability and write code that isn't actually re-usable).

Civilization, as we know it, will end sometime this evening. See SYSNOTE tomorrow for more information.