Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Programming IT

The #NoEstimates Debate: An Unbiased Look At Origins, Arguments, and Leaders 299

New submitter MikeTechDude writes: Estimates have always been an integral part of the software development process. In recent years, however, developers, including Woody Zuill and Vasco Duarte, have begun to question the efficacy, and even the purpose, of using estimates to predict a project's cost and time line. A fierce debate has sprung up on Twitter, between those calling for an end to estimates and those who continue to champion their use in a professional setting. On the surface, it would appear that the debate is black and white. Proponents of the #NoEstimates Twitter hashtag are promoting a hard stop to all estimates industry-wide, and critics of the movement are insisting on a conservative approach that leaves little room for innovation. However, the reality of the debate has unfolded in far more complex, nuanced shades of gray. HP's Malcolm Isaacs digs deep and pinpoints where the debate started, where it now stands, and what its implications are for the future of software development. Meanwhile, Martin Heller offers his less unbiased approach with his post, #NoEstimates? Not so fast.
This discussion has been archived. No new comments can be posted.

The #NoEstimates Debate: An Unbiased Look At Origins, Arguments, and Leaders

Comments Filter:
  • Estimates (Score:3, Insightful)

    by Anonymous Coward on Thursday September 24, 2015 @08:19PM (#50593421)

    Correct:

    How long will it take you to do this list of things?

    Incorrect:

    How long will it take you to do this thing that nobody has ever done before and which may or may not have these features, and we may need to add new requirements when we're halfway through but we won't know until we get there.

    One of these is merely difficult. The other is doomed to failure from the time The Boss opened his mouth.

    • Re:Estimates (Score:5, Informative)

      by gweihir ( 88907 ) on Thursday September 24, 2015 @08:53PM (#50593587)

      Not so. The second one has a correct and professional answer: "I do not know. This will require a pre-study. But adding new requirements during the process is right out, then the pre-study has to be repeated and the project reset." and on the pre-study you _can_ deliver a reasonable estimate.

      It is not only bosses demanding infeasible things. It is also coders not enlightening them on what is possible and what is not.

      • Re:Estimates (Score:4, Insightful)

        by PopeRatzo ( 965947 ) on Thursday September 24, 2015 @09:30PM (#50593791) Journal

        Not so. The second one has a correct and professional answer: "I do not know. This will require a pre-study. But adding new requirements during the process is right out, then the pre-study has to be repeated and the project reset." and on the pre-study you _can_ deliver a reasonable estimate.

        You are assuming the corporation you work for is a rational actor. They are not. They are products of paperwork and exist as golems to extract maximum profits at any cost.

        The management you work for isn't to blame, because they're just trying to feed Moloch too. They are also consumables.

        Looking for rational expectations and behavior in the 2015 workplace is like Captain Yossarian looking for rational expectations and behavior in the military. If you're not crazy, you're not paying attention.

        • "You are assuming the corporation you work for is a rational actor. They are not. They are products of paperwork and exist as golems to extract maximum *short term* profits at any cost."

          There, corrected for you. Corporations, not being rational, as you said, usually act childish: they'll take one today even if it obviously mean lose ten tomorrow (yes, that's an hyperbole: change "today" with this quarter or next and "tomorrow" with in two years).

          • by khchung ( 462899 )

            "You are assuming the corporation you work for is a rational actor. They are not. They are products of paperwork and exist as golems to extract maximum *short term* profits at any cost."

            There, corrected for you. Corporations, not being rational, as you said, usually act childish: they'll take one today even if it obviously mean lose ten tomorrow (yes, that's an hyperbole: change "today" with this quarter or next and "tomorrow" with in two years).

            If the chances of being there "tomorrow" is small enough, giving up ten tomorrow to take one today is the *most rational* choice.

            After seeing the umpteenth coworker being "let go" for not reaping in enough short term profit, you need to be *irrational* to still think long term for the company.

            The blame starts all the way from the stock holders demanding short term profit.

      • by gl4ss ( 559668 )

        yes. you can say "I don't know" and then SOMEONE will make some sort of estimate anyways. because you need that for budget for making a quote to sell it to the client.

        could just as well be #noquotes.

        what's really needed is for the sales people to not sell something they don't know what they're selling, because then you end up with a project that's starting and has a deadline before anyone knows wtf it's supposed to even do.

        • by schnell ( 163007 )

          what's really needed is for the sales people to not sell something they don't know what they're selling, because then you end up with a project that's starting and has a deadline before anyone knows wtf it's supposed to even do.

          Then how would anyone every buy or sell any professional services work, or custom system development? If you are building a new ERP system for a client, you can't tell them "Well, we'll build it for you and then tell you how much it will cost after we're done." Maybe you can get away with a "cost plus" approach in the government (and we've all seen how well that works in terms of conserving taxpayer dollars), but in the real world a customer needs to budget for development well before it's delivered.

          Or take

      • by plopez ( 54068 )

        That sounds like a waterfall.

    • Re:Estimates (Score:5, Insightful)

      by Spazmania ( 174582 ) on Thursday September 24, 2015 @09:58PM (#50593911) Homepage

      If you can't produce a reasonably accurate estimate you may not have asked the right question.

      How long will it take you to do this thing that nobody has ever done before

      This is not the right question. The right question is: how long will it take you to assess this thing that nobody has ever done before, and devise strategies for doing it, and develop them to a point that you can estimate how long executing these strategies will take.

      Nothing wrong with saying, "I need four weeks to research this before I'll be able to give a reliable estimate on implementation."

      • Also perfectly reasonable to say: "I don't have the background in this field of study to implement or reliably estimate the cost of implementing the requested technology. I would need assistance from experts in X, Y and Z before I could produce an estimate."

        • And you get the experts to help make the estimate. Then they say it is too long and cut it down to 1/3rd the time estimated. And the project ends up going way over what was estimated.

          I have stopped caring about the estimates. The boss can make his fantasy timelines all he wants. Sometimes, when it is a small project I come in on time. Other times the project ends up going over. It ends up cutting into the next project, which has a firm stop date, so they don't give even the original amount of time estimated

  • Just stop (Score:5, Insightful)

    by Anonymous Coward on Thursday September 24, 2015 @08:24PM (#50593459)

    No, hashtags are not movements. If you think so, you either have no clue what a movement is or no clue what a hashtag is, and I'm guessing it's the former. Talking about things on Twitter is talking and that's it. It's not some kind of political action.

    • by Tablizer ( 95088 )

      No, hashtags are not movements.

      If you eat a lot of Chex Mix, your movements will look like hashtags.

    • It becomes political when the amount of people is high enough.
      As it is "making news" I guess it is a high enough involvement of people and hence: political and hence: a movement.

  • by Anonymous Coward

    We have this already; it's called agile. Forget about the scrum and the planning meetings, they're get emphasized by shitty teams and PHBs because they're something people are used to, namely meetings, and they're easy to do. They're not required and arguably the least important aspects of agile.

    The point of agile has always been:
    1) Figure out what the most important feature you need to do next.
    2) Build it and make sure it's rock solid.
    3) Keep repeating #1 and #2 until the client is satisfied.

    You add on t

    • by Entrope ( 68843 )

      You forgot that sometimes you need to stop when the client runs out of money, and agilistas mostly strive for that endpoint rather than shipping a completed work.

      • "You forgot that sometimes you need to stop when the client runs out of money"

        Agile focus on each deliverable being, well, deriverable: when the customer runs out of money it should get a fully viable product.

        "agilistas mostly strive for that endpoint rather than shipping a completed work."

        Another tenet of agilism is that it is a thing of the customer as much as it is a thing of developers. If the customer doesn't make its part is no surprise it ends up with burned fingers.

        • by Entrope ( 68843 )

          No, Agile focuses on each sprint ending in an output that does something -- ideally something sensible, but not necessarily something useful. If you're replacing an existing process or product, it is not useful until it becomes more functional or efficient than what it replaces, and that will probably take many sprints.

          Every time I hear agilistas talk about their tenets, I am reminded of Zed A. Shaw's rebuttal [programmin...fucker.com] to them, and how they don't have effective counter-arguments to his "what they mean" interpretati

  • The real problem (Score:5, Insightful)

    by wonderboss ( 952111 ) on Thursday September 24, 2015 @08:54PM (#50593599)

    is giving estimates without a detailed design.

    Imagine this interaction:
    Customer: I want you to build me a house.
    Contractor: Ok, How many square feet?
    Customer: I don't know. When can you start?
    Contractor: We can't start until we have plans drawn up.
    Customer: I don't have time for that. How much will it cost?
    Contractor: I can give you a rough idea once we've nailed down the square footage, number of stories, type of foundation, and some other details.
    Customer: You are wasting my time with all these questions.
    Contractor: Go Away.

    Yet software developers agree to this situation, or are forced to agree to it, all the time.

    • And building a house is a fairly simple task compared to writing some programs. You should better compare software to digging tunnels in the mountains. You never know what type of stone is ahead, and if you reach sand, you have to cool it so that it's stable etc.
      You can make small test drills in order to find that out, but you won't know it for the complete length of the tunnel. And if management now demands that the tunnel has to be larger, it means alot of effort, the longer your tunnel already is.

      • You should better compare software to digging tunnels in the mountains. You never know what type of stone is ahead, and if you reach sand, you have to cool it so that it's stable etc.

        and yet tunnel diggers manage to work on-time and on-budget over and over and over again...

      • by Dahamma ( 304068 )

        And building a house is a fairly simple task compared to writing some programs.

        And writing a program is a fairly simple task compared to building some houses.

        That was the OP's whole POINT. If you have clear and complete architectural and engineering plans, both can usually be estimated with reasonable accuracy. If you don't, then neither can.

      • I think people that are good at estimates are doing the same things over and over. Such as adding a small feature to an existing product. But designing and building a new product from scratch, you just can't estimate that.

        A: "How long will it take to write the driver?"
        B: "I don't know, we don't have documentation yet."
        A: "Well make a wild ass guess then, I need a number to fill in."
        B: "Um, 6 months."
        A: "Stop sandbagging."
        B: "Ok, six hours."
        A: "Really, that fast?"

    • Re:The real problem (Score:5, Interesting)

      by phantomfive ( 622387 ) on Thursday September 24, 2015 @09:06PM (#50593661) Journal
      Robert Martin recently wrote a book called Clean Coders [amazon.com] which discusses exactly how to deal with that problem.

      Essentially, he says if you want people to treat you like a professional, then you need to act like a professional. I highly recommend that book, it's good.

      Refusing to do estimates is not acting like a professional.
    • Customer: build this
      Developer: OK, it should take X
      Customer: great

      Customer: why is it late?
      Developer: oh, I used a bunch of new technologies and techniques. Now it does all this crap you never asked for, but I was able to pad my resume.
      Customer: but it doesn't even do what I asked for
      Developer: you idiot, you didn't spec it correctly.

    • by khasim ( 1285 )

      Isn't that known as "gathering requirements"?

      It can be difficult and they can change and they will probably be incomplete ... but as you get more experience you should be better prepared to deal with those issues.

      I've seen a company build a new production center and not know where the people would be who would be operating it. Some of it was backwards. We ended up putting down tape to delineate the different areas so they could be painted. So yeah, stupidity is rampant.

      But the contractors all got paid. They

    • Giving estimates without a detailed design is bad.

      But the thing is, often giving estimates WITH a detailed design is no better.

      So much of software development is utterly variable - perhaps you get a guy who doesn't know some aspect of the system they are building in and needs an extra week, while another person does not. That alone is a whole week lost or gained depending on perspective.

      And there are thousands of things like that in any given bit of software. The approach you take to design, the overhead

      • "The approach you take to design, the overhead of process, even just unexpected interpersonal contention between team members who may not have even been allocated to a project before you are supposed to give an estimate."

        Yes. And the way RFPs work are not helping here. Even if we accept the RFP to be an excessively precise one (which is usually not the case) what does exactly the customer expects? For the providers having a team of people twiddling thumbs just in case they win the bid? No. What they usu

    • by plopez ( 54068 )

      Part of the difference is that a house is a tangible object. You can see it, feel it, smell it, etc. Software is not, it is largely an intellectual excesses. That makes it hard even for good developers. I have even used a house metaphor at times when talking to customers as in "you're asking us to tile the second floor bathroom before we have the foundation in place".

    • Replace customer with product/project manager and that sounds right too.

      But reality need not intrude on the process. I remember something I worked on that got a product of the year award based solely upon a mock-up when the real product wasn't even functional.

  • One of the major complaints about estimates is that it "takes too long." Seriously, if estimations take any appreciable amount of time, you're doing them wrong.(unless you need to estimate some massive project, in which case you understand why estimates are needed).

    If you want to remove the "time sucks," get off slashdot, get off twitter. When I turn off the internet while working on difficult code, I literally get twice as much done. I've measured this several times (and you can tell from this comment ho
    • by Kjella ( 173770 )

      One of the major complaints about estimates is that it "takes too long." Seriously, if estimations take any appreciable amount of time, you're doing them wrong.(unless you need to estimate some massive project, in which case you understand why estimates are needed).

      Usually this is because you've already estimated it to the best of your ability but the powers above aren't happy with the uncertainty, where they harass you into giving a magic number or narrow little gap or to talk down your estimate until it's the number they're happy with. Or if you're really lucky get a litlte time for research/experimentation/prototyping but in practice it'd just be faster to start on the implementation, if you know this is a task that in practice will need to be done regardless. I've

      • Usually this is because you've already estimated it to the best of your ability but the powers above aren't happy with the uncertainty, where they harass you into giving a magic number or narrow little gap or to talk down your estimate until it's the number they're happy with.

        If someone makes an estimate for you, or forces you to make a lower estimate, then you have no obligation to meet that estimate.
        Be professional, and hit your estimates, but learn to let people know that things take time. These are soft skills.

  • Be honest (Score:5, Interesting)

    by cowwoc2001 ( 976892 ) on Thursday September 24, 2015 @09:01PM (#50593631)

    Estimates should be used to prioritize features (cost / benefit) as opposed to being used to set hard deadlines.

    Estimates should be one of "hours", "days", "weeks", or "months". It is fairly easy for most people to differentiate between features that take hours to implement vs weeks. In my experience, exact durations with multiples for padding have proven to be less useful / accurate than the former method.

    • Estimates should be used to prioritize features (cost / benefit) as opposed to being used to set hard deadlines.

      I have argued for a long time that, when managing projects, people should focus less on deadlines and requirements, and more on prioritization. For example, all the stakeholders can agree on a project to be completed with a certain feature set by a deadline of November 1st for a budget of $20k, but often enough, that's not really the information you need to know. What's just as important as knowing those project requirements is knowing, when you reach the point where not all of those requirements can be m

  • In the 70s, we got Mythical Man Month
    in the 90s we got Extreme Programming, followed by Agile.

    Now we get #NoEstimates. I think we can do better.
    • Extrem programming is-an agile method.
      So saying Agile came after XP makes no sense :D

      And in agile methods you do estimations ... but in our times usually not based on time but complexity.

      • eh,

        Agile Manifesto - February 11-13, 2001
        Extreme Programming Explained - published October 1999

        That's good enough to say "it came first" :)
        As long as you understand, I'm not going to argue about the definition of "first."

        And yes, I learned this tip about estimation from agile:
        When you make an estimate, afterwards check to see how accurate the estimate was, and use it to improve the next time.
        Using this method, over time I've gotten fairly good at not missing estimates. The only times I miss are
        • by Greyfox ( 87712 )
          If you follow along at the Cunningham and Cunningham website, it's pretty easy to see the clear evolution of both concepts. Agile very much evolved from extreme programming. Most companies that I've encountered that claim they're agile really aren't, though. They're agile but they don't have time to write tests, they don't empower their programmers to limit the number of stories in a cycle, and they very frequently have half-hour to hour long daily scrums. In short, they just add a bunch of agile paperwork
          • I've wondered about the C2 website......did the ideas get developed there, or Was it a place people merely recorded after the ideas were developed?

        • Agile Manifesto - February 11-13, 2001
          Extreme Programming Explained - published October 1999

          Does not change the fact that XP is an agile method, too :D I guess if we dig a bit around we find a few more agile methods that come before the "Agile Manifesto". After all the manifesto was written down as several agile methods showed that they work (in a certain context)

      • Re:Downward Spiral (Score:4, Interesting)

        by phantomfive ( 622387 ) on Thursday September 24, 2015 @09:39PM (#50593833) Journal
        Incidentally, This Manifesto [antiagilemanifesto.com] against the agile manifesto entertains me.
  • When I was working on a videogame a number of years ago, I was asked by the publisher to come up with an initial schedule. We had a more or less fixed deadline, and while we knew roughly what we were going to be working on, the design phase of the game hadn't even begun. I started working on a very rough outline of the phases of the game development based on my previous experience with such projects. Naturally, it was somewhat vague, because we didn't have a design yet.

    The publisher rejected the timeline

  • by nine-times ( 778537 ) <nine.times@gmail.com> on Thursday September 24, 2015 @09:22PM (#50593757) Homepage

    I'll admit that I'm not a developer, so I may not have a firm grasp on the relevance of everything being talked about. However, I've managed my share of projects, and I definitely think there's reason to doubt the value of estimates for all kinds of projects. Software development projects are not unique in that regard.

    Now, I want to start by pointing out the obvious that you often have to make some kind of estimate. Even if the estimate isn't very precise, you have to make some kind of guess-- is this going to take 1 day, 6 months, or 5 years? Being practical, people have to have some idea of what they're getting into, or they can't make decisions.

    On the other hand, estimate can only be accurate insofar as the scope of the project is well defined and well understood. For tasks that you do frequently and know exactly what needs to happen, accurate estimates are not very difficult. Even if you are bad at estimating, you can measure how much time and money is spent on those repetitive tasks, and then use that data to figure out how much time and money it typically takes. However, as the scope of work is less well defined, or the nature of the work is less well known, the accuracy of the estimate will be worse.

    Imagine building a house. If you're building 100 houses in a development, and you do that work often, and you've already build 30 houses and know how much the labor and materials cost, then you can probably make a good guess of how much time and money it will take to build the remaining 70. However, if someone asks you to "fix all the problems with their house," and you don't know what shape their house is in, what it means to "fix" it, what the laws are regarding construction in the area, or what the local materials/labor cost, then your estimate won't be worth much.

    And this brings me back to the issue of "precision" rather than "accuracy". I think part of the issue is to provide an appropriate expectation of precision when providing estimates. I frequently have to provide estimates, and some of them are wildly wrong, but when I'm not confident in the estimate I'm providing, I'll also provide some kind of disclaimer. I admit that I don't know all the details about the situation I'm getting into, and that my estimate could be off. The thing that I'm saying will take 6 weeks might take 2 months. Maybe 2.5 months. Maybe more. Not 6 months-- at least not unless there's something really unexpected or some kind of mission-creep.

    But this is really part of a larger problem: the ineffectual nature of "plans". There's a famous quote, something along the lines of, "no battle plan survives the first contact with the enemy". Again, there are projects where the scope is defined and the work to be done is well understood, and in those cases, you can do conventional project planning. You can set milestone dates and make gantt charts, and develop a whole timeline and budget. But on the other hand, Donald Rumsfeld was on to something when he talked about "unknown unknowns". Often when you are embarking on a project, you're not even aware of the obstacles you're going to face, and so you can't account for them. This doesn't mean there's no point in developing a plan or a schedule. It means that your schedule has to be flexible in proportion to the likelihood of "unknown unknowns" and other contingencies outside of your control.

    I think if you want to improve the situation, the answer isn't to stop making estimates or project plans, but to develop better methods for quickly estimating the precision of your estimates, providing a margin of error, or the level of flexibility needed in a project. However, I think the #NoEstimates people are correct to point out that there is often diminishing returns on trying to set deadlines and budgets. It doesn't make sense to spend a week refining your plans for a two-week project.

    • by Greyfox ( 87712 )
      That very much hits the nail on the head. Most of what I've done has been maintenance and not new development. If I'm doing new development on my own and I'm trying to learn something new, it's hard to estimate. If it's tools I'm familiar with, I can be reasonably accurate.

      There's another side to that story as well -- most programming positions are actually not new development. Even if you're getting in early on a project, there's probably already a lot of framework code in place and likely a design. If y

    • Actually, when you don't know the scope in advance, you need to FLIP the estimate into a maximum allowed effort. Ask the customer how much they are willing to spend on the problem for now, and then do all that you can for that amount and cycle back. When you report how much you did, you'll also know much better how much is left to do. Then you can make another ask.

      Works every time.

  • From the article:

    That gave our VP enough confidence that he "only" doubled our estimates and offered the customer a firm fixed price. This contract was a success for all concerned: we came in under our estimated time and cost

    So two highly experienced developers came up with an "estimate" that was off by nearly a factor of two (in came in "under time" but surely not by half).

    How is that really an estimate? From the standpoint of raising that as a banner in support of estimates, how is that success? Remembe

  • by MrKaos ( 858439 ) on Thursday September 24, 2015 @10:34PM (#50594059) Journal

    There are *several* formulas to do an estimate and several more to tell you if your estimates are on track.

    If you understand why estimates are required, you are a business person, if you understand why they are so difficult you are a developer. Managing estimates is a 'Project Management' task and a good PM will keep the pressure of the team by also managing the stakeholder expectations, which is what we are really talking about here.

    Complex estimates are closer to the contract and simple task estimates are closer to the metal. If anyone asks for an 'accurate estimate', run - they are an oxymoron who won't de-scope so that deliverables are met. To me it is an immediate sign of project failure.

    Estimates are just a tool that are a balancing act for getting the budget required to do something. Good estimates are achievable by iterating three simple questions pessimistic, realistic and optimistic estimation for a smaller task of a large project. After that there are several other formula to determine if you are ahead, behind or on schedule. Ahead or on schedule - great, behind - de-scope. What the final product looks like is a function of the contract that determines the critical path and managing the expectations to get there. Estimations on a small project however are usually a waste of time.

    The last thing you want to do is go back to an accounting department or client for more budget because the estimates are way off anymore than having no estimate at all and asking for a big bucket of money that won't get approved and no developers will ever get employed to do that project.

    Using 120 characters to discuss such a complex subject, that can't possibly hope to encapsulate the arguments required to understand it, is pointless.

  • In reading these comments the phrase "Giving estimates without a detailed design is bad" pops up in one form or another. Basically that is asking for a waterfall. I am somewhat uneasy how often it has appeared even in this day and age. Here are my observations on the topic:

    1) Forget good requirements, no one has them. No one knows what exactly the software will do at the beginning of the process. One thing I am certain of is that in about 18 months, if you are competent and lucky, you will start to have a g

    • " Often too software requires a review of business process which shed light on how a business is *actually* run, not how management *thinks* it is run. This will cause requirements shift."

      That's a great line, and your anecdote [1] is awesome. Thanks for sharing.

    • Forget good requirements, no one has them.

      ....

      It is never really done.

      ... and the loop is closed.

      Though on global scale, IME, another problem is that the former is relatively well accepted, but the later should be never mentioned to the customer. Or to your sales. Or to your PM. Or to your colleagues.

      Most people need the certainty about the results. Because result is something concrete, while the process is something distant. Because most people spend to little time understanding the whole development process and their role in it.

      P.S.

      Lots of little releases to throw them a bone and to get feedback

      Not all customers are OK with that.

  • Those who are paying the bills want estimates. Those who are getting the money want a blank check. It's that simple!

    There are ways to create good estimates, but it does require discipline and training. Steve McConnell wrote an excellent book on the subject. Unfortunately, many software developers aren't well trained in this art. This is a serious failing in many of our computer science degree programs.

    • No, everyone wants estimates. No one wants or is willing to start a software project they do not have some idea how much work they will need to do to finish it. And if you are unable to estimate the time it will take to do, you are equally unable to program it. I would probably not write a single line of code if I could not tell a 30 minutes project from a 500 million man hours one.
    • Estimation is such a crucial skill, too. If you can't do it, you can't make good design decisions. Imagine this scenario:

      You are adding a feature to your project. Should you:
      A) Spend time integrating a library into your project
      B) Spend time writing the code to do that feature.

      If you don't know how long B will take, you can't possibly make the right decision. Estimation is just one part of the skill involved here, in addition you'll need to know how the library will affect the long-term stability of y
  • by joe_frisch ( 1366229 ) on Friday September 25, 2015 @12:36AM (#50594499)

    Estimates are useless as a measure of how well an engineer is performing. How far he is ahead or behind schedule only indicates the extent to which he was able to get away with padding his estimate in the first place.

    That said, estimates ARE very valuable when you have a complex set of interlocking projects and resources that can be tasked in different places. This is especially true if external pressure require that a project be done on an exact date.

    To take an extreme example, if the launch window for Europa is at a known date, the spacecraft firmware must be fully tested and installed by that date. Working backwards that says when the first version must be ready. The estimate helps decide what resources should be applied, and later it lets you know if you are so far behind that you need to change the launch date to the next window (over a year away). That affects budget etc.

    At SLAC we have complex projects that require the work of lots of people to all come together. This results in very rigid schedules - There is typically a 2 month window for major upgrades, if you miss it, you wait a year. If someone working for me doesn't like doing estimates, I basically say "we need a guess. I can guess or you can, but since you are doing the work, your guess will be better than mine".

  • by Ronin Developer ( 67677 ) on Friday September 25, 2015 @12:57AM (#50594567)

    I have worked in the industry for 20+ years and here are my observations - granted, I have worked in smaller companies (i.e 25-4000) and startups.

    Estimates work as a means to determine the work effort for a given set of features. They are not to be used for setting schedules and deadlines by themselves. They are to be used for budgeting and cost planning. And, they are not to be done without a detailed design meeting the agreed upon requirements.

    Unless your client is very rich and/or stupid or you have a large surplus of venture capital in your startup, you better be concerned with the work effort and time to have your product in a usable state. When you can tell a client that a project is going to take time X and cost Y and meet those values, you gain credibility and trust. In the digital advertising world, those with credibility and trust become the agency of record (AOR). And, the client will stick with you as their AOR until you royally screw up and fail to deliver what was promised, when promised and for the agreed upon price.

    You DON'T ask a developer how long something will take - they invariably will underestimate the work effort. Instead, at least until you have measured delivery rates for your team members, you use industry standards. You can ask the developer and then compare their estimates with the actual time and effort. When their estimates start matching up, you can ask them estimate their own assigned work. It can be a good learning experience for them.

    Some projects don't require estimates. We had projects that fit a template model based earlier work. We knew how long it took, on average, to fill the various fields of the template. Throw in the project management, QA and deployment components and its pretty easy to do.

    When people claim Agile isn't compatible with estimates, it's probably because the team isn't concerned about documentation or planning. They tell you that the system has too many variables and they don't have time or resources to keep the design up to date. I call BS. If you can't do it, then add someone to the team who can. There are great tools for doing design work and capturing requirements at all phases of a project - use them.

    Even with Agile, you should layout out a basic design or framework in the early stages of the project. Then, you can determine how long other features will take and what their dependencies are before you attempt to implement them and emptying the client's wallet. Then, you base the number of sprints based on that information. Since you are supposed to have a working product at the end of each sprint, you should be able to tell the client what features will be in each deliverable and cost. If they want to change the requirements or add new features or change functionality, you still have to plan how long those features will take and in which sprint you will deliver a product that meets those changes.

    • Then, you base the number of sprints based on that information.

      I think your brain is hardwired to the waterfall method, and you're thinking of Agile as a series of smaller waterfalls, one after the other. The whole point of Agile is admitting that you don't know where you're going to end up. You try to figure out how to test your basic assumptions as soon as possible -- no, really, as soon as possible, maybe even without writing a single line of code -- then iterate based on what you discover.

  • All I need to do is to look to see where a project lay in the realm of my experience and knowledge. I can tell you that if you want me to make hello world in a language I know well on a platform that I know well that it should be under 5 minutes from beginning to end. But if you want me to program an image recongintion system that can tell if a sparrow is content or agitated on a VAX/VMS. Then I will give you an estimate of maybe 5 years before I can even give you a proper estimate having gathered up the ex
  • choices (Score:4, Insightful)

    by Tom ( 822 ) on Friday September 25, 2015 @05:25AM (#50595355) Homepage Journal

    As they saying goes: Fast, cheap, good - pick any two.

    You can usually solve one problem by another. If you see you can't hold the deadline, you can throw more manpower at it (not cheap anymore) or compromise on quality. If you see the budget runs out, you can put the project into idle times (not fast anymore) or compromise on quality.

    Sadly, quality is the part that management, customers, clients and developers understand the least. Everyone understands deadlines - either you are done on that day or you are not. Everyone understands money and to convert developer man-hours into money is not so difficult. But quality is tricky. If it runs, ship - because management, customers, etc. they see if it is running, but not what's going on under the hood. And developers too often don't understand that quality is subject to combinatorial explosion - shortcuts don't add up, they multiply.

    But because it's the least-understood part of the equation, and compromises matter so much but are not easily visible as long as the core operation functions, software in generally is so absolutely shoddy.

  • I've been looking into building a house recently, and it taught me something about software development:

    To understand what I would get for how much money, I went to a "park" of houses. 20 or so houses of different styles and sizes, with price tags. So by spending a few hours walking through them all, I could get a pretty good understanding of what I would get for which price. From that point, I can start an informed discussion with a company asking for the house I want, based on what I saw, with an idea of

  • Has anyone ever told these people that someone somewhere up the line has to pay for them to f*** about? I'd like to build you a house. I don't know yet how big it's going to be, because I haven't designed it yet. I don't know how long it's going to take to build it. I want you to pay me an indeterminate sum of money for it... And I want you to pay for it before you get it. In fact I want you to start paying me now, and keep paying every month until it's done. I'll tell you when it's done. Who wants to buy

The reason computer chips are so small is computers don't eat much.

Working...