I can estimate some tasks very accurately. I know that adding this new flag to my system will take a day.<p>Other tasks I can accurately say I don't know how long they'll take. This new feature is... a couple of weeks? This new application is... a few months? I can roughly guess (estimate!) but there's a wide certainty margin.<p>That uncertainty is never built into the mathematical model used by project managers, which is invariably a simple addition of scalar estimates. The only common way of dealing with uncertainty is to <i>pad</i> the estimates (multiply by two, etc), but that's still not a statistical boundary -- it's just a scalar.<p>Furthermore, when adding uncertain values, they wind up not being independent, for a number of reasons -- the lessons from one feature are carried on to the next, or the next task is easier because of new existing code, or because as you approach the original deadline you invariably throw out feature requirements. So you can't necessarily just add all the uncertainty values.<p>So a better approach to estimation would be to formulate a (<i>simple</i>) model which encodes each estimate as {guess, uncertainty, independence} and then provides a function for compounding the guesses and uncertainty and independence factors in a realistic way.
One of the comments on the original article nails it. The real problem is conflating "estimates" with "deadlines" or "commitments". You see it with the casual replacement of "story estimating" with "story sizing" in our language. "Sizing" implies a degree of certainty that may not be there.<p>Estimating is most definitely useful. But you have to fight every step of the way to keep an estimate from becoming a "promise". Promises that can't be kept are not good for any of the parties involved and lead to things like developer burnout, poor quality, technical debt, surreptitiously reduced scope, lack of trust...it goes on and on.
Pardon my French, but it's a load of bollocks. Sure, I hate estimating and I'm bad at it, but I've worked with many others who were better than me at it and <i>did</i> consistently deliver what promised, when they promised it. And yes I'd much rather just sit and contemplate and re-re-rework 'the design' and be all-important about 'it's done when it's done' - but I fully well understand that any customer will just fire me and take someone who just does what he says he will.<p>Building construction is also fraught with unexpected events and project management issues etc., but I'd laugh any building who would propose that I just keep paying them until it's done, or who will start building and go home when whatever budget I give him is used, out of the room. Why would my customers be any different?<p>(articles like this poison the minds of young impressionable developers who think it's actually reasonable to have ideas like this, btw, which is why we shouldn't just shrug them off)
Software time/cost estimates are essential. If I run a business, I need to have some understanding if an investment will have a return. If I have no way to gauge that at all, then there are many more predictable endeavours where I can spend the money and realize a return. When you invest, do you simply say the future is unknowable and bet on raw emotion? I should hope not. That's not to say you may err in your judgment of available facts, you may still lose, but at least you understand some of the parameters about what constitutes success.<p>Software time/cost estimates are exactly that: estimates not guarantees. We tend to think of such things in terms of project management and contract enforcement. If anything, that is where we go wrong. What we should do is not try to understand the whole project in terms of an unalterable roadmap, but rather as a guideline for managing expectation and for informing decisions that are made during the course of a project. I use my estimates to sell the project, yes, but I also tell the client that as we go along we will be making many decisions that will move us away from our initial plan as we better understand both the issues and opportunities a project affords. Sometimes spending more time than planned will make sense, sometimes it won't and we cut the feature. Sometimes we find that we have failed to identify important features and sometimes we identified a feature early on that isn't as important as we thought. The overall project plan and estimate does set a benchmark to ensure the economics are still correct, after all if we lose that we lose the point of the project entirely, but we don't turn that plan into dogma. We don't lose sight of the reason that caused the project to exist.<p>So, yes, we need estimates no matter how hard they are to get accurate. What we need to stop doing is equating that estimate as an oath to be upheld regardless of what new knowledge comes along.
If I'm ever asked for an estimate, it's after the project schedule has already been set in stone.<p>On my current project, I am the sole full-time developer. The requirements were gathered from the client without my involvement. The schedule was laid out without my input. Then the whole thing was dropped on me.
A more appropriate question is not, does software estimation help improve project management, but is project management a suitable model for software?<p>I am a proponent of the idea software is a new form of literacy. We generally do not project manage the next paragrpH or the next chapter. writers are often faced with deadlines, but rarely have to justify themselves on a daily basis.<p>Improving estimation will just result in slightly better inputs to a process that at best hinders us and sucks creativity and joy.
I have to laugh when I see these posts. So, software development is a special activity that should not be constrained by budgets or deadlines (or estimates)? Where do I sign up? There are so many strawmen here I can't possibly address them all. If you can't provide a credible estimate for a piece of work, you either a) aren't very good, b) don't properly understand the work to be done, or c) perceive some aspect of the job that is unknowable to you (through lack of experience or other novelty). Fixing each of these is up to you. 'a' is obvious (you either work hard to get better or find something else to do). 'b' means you need to ask more questions that allow you to sufficiently complete your understanding of the problem so an estimate is possible. 'c' means you need to isolate the novelty and explain that this part of the problem is new to you and you are not qualified to provide an estimate. Perhaps someone else can provide that insight or you can define an initial activity designed to help you better understand the novel problem until you can estimate the remaining work. NO area of engineering is so cut and dried that estimation is easy.<p>What IS common is a combination of poorly defined projects and a profound lack of self-awareness. By all means, push back against poorly defined projects ("I can't estimate the work until you tell me what it is."). Lack of self-awareness is squarely in YOUR lap ("I don't understand why it always takes longer than I thought it would..." Well, duh, maybe you should consider that reality for what it is and account for it next time).<p>Estimating work and committing to those estimates is what a professional does. Deal with it. If estimates are imposed on you that you do not agree with, that has nothing to do with the virtue of estimation. That's a social problem, not a technical one.
There are Mathematical Limits to Software Estimation: <a href="http://scribblethink.org/Work/kcsest.pdf" rel="nofollow">http://scribblethink.org/Work/kcsest.pdf</a>, <a href="http://scribblethink.org/Work/Softestim/softestim.html" rel="nofollow">http://scribblethink.org/Work/Softestim/softestim.html</a><p>In general, unless you've done something very similar before, estimation can't be done accurately. Your manager should know and accept this.<p>The best you can do is probably this: Repeatedly split the project into tasks, estimate the time it will take for each, until the next task takes several hours, and then do the next task. Keep track of estimates and actual times spent. Your manager should ask you to do this and keep it updated. Joel Spolsky wrote something similar here: <a href="http://www.joelonsoftware.com/articles/fog0000000245.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000245.html</a> (I'm sure I read similar advice elsewhere, but can no longer find it.)<p>It should go without saying that you should include unit testing, code review, debugging, etc. in your estimates. And, of course, making and updating the time estimates.<p>The project, when "complete", will still usually require maintenance, so work on the project only stops when the software is no longer used.<p>You should never be given deadlines, as you won't know in advance what problems you might encounter, and the quality of your work (and probably your health) will suffer. This will result in a build up of technical debt, increasing maintenance costs.<p>It's well worth reading The Mythical Man-Month, especially if you're managing a project, or working with others on the same project.
I've found that using past data is very helpful. Look at your past projects, compare your initial estimates to the actual outcome when the project was finished. After a dozen or so projects, you should be able to formulate a percentage buffer to help you get closer on future estimates. Continually make this assessment and eventually you will find that you are getting much closer to accurate budgets/timelines.
<i>Open article</i>
<i>Ctrl+f "Risk Management"</i> "Zero results"
<i>Ctrl+f "Risk"</i> "Zero results"<p>Now, I don't work in software engineering, I work in traditional engineering, but I find the lack of any formal Risk Assessment, Management or Lessons Learned in any Project Management methodology/framework a little scary.
I use my best judgement to estimate the time the task will take. I then double that number and report that as my estimate. For times great than one month - multiple by a time and a half instead.<p>One month? No, six weeks. Two hours? No, four hours.<p>The reality is typically somewhere between the two numbers. So the estimate remains fairly accurate and most things are finished ahead of schedule.<p>There are too many variables that cannot be accounted for when giving an estimate. How often am I going to get interrupted? Is there going to be legacy code that causes a bug to surface and has to be refactored? Etc.