TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why are software development estimates regularly off by a factor of 2-3?

311 pointsby cviedmaiover 11 years ago

65 comments

_wwz4over 11 years ago
So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing. Let&#x27;s extend the analogy somewhat... this isn&#x27;t your first hiking trip. In fact, you&#x27;ve been on dozens and dozens of hiking trips. You&#x27;re an experienced hiker. Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination? The reason is that if you miss your estimate, it probably won&#x27;t matter. Your sherpas will be there at every stop with your food, water, and tent. You have nowhere to be any time soon, so estimating your time just isn&#x27;t important enough to worry about.<p>Developer estimates are regularly off because they seldom impact the developer directly. Experienced development managers will pad the hell out of the developers who give them the worst estimates. Most developers will explain all the complexity of what threw their estimate off without acknowledging the huge mistake of not anticipating extra complexity in the first place.<p>My estimates in my early career were no better than anyone else&#x27;s, ie way off -- especially for more complex projects. I&#x27;d explain what happened to my managers and soldier on. The very next task that came up, I&#x27;d give my manager some best-case estimate of how long something would take and the cycle would begin again.<p>That all changed once I started to do consulting for myself using &quot;not-to-exceed&quot; pricing. The first multi-month project I did killed me. My effective hourly rate went down to sub McDonalds levels and took much longer to deliver than I had expected. After that project, I did a post-mortem on the project to figure out where I went wrong. I came up with several spreadsheet templates and checklists to run through before giving any more estimates.<p>Mostly I just concerned myself with getting a hell of a lot better at estimating project duration and difficulty. Like most things, when you really pay attention to it and practice it, you get better at it.
评论 #6821086 未加载
评论 #6820800 未加载
评论 #6820760 未加载
评论 #6820900 未加载
评论 #6821887 未加载
评论 #6820743 未加载
评论 #6821054 未加载
评论 #6820789 未加载
评论 #6821421 未加载
评论 #6820828 未加载
评论 #6820777 未加载
评论 #6821193 未加载
评论 #6820741 未加载
评论 #6822786 未加载
评论 #6820969 未加载
ebiesterover 11 years ago
It&#x27;s simple. People don&#x27;t like the honest answer.<p>As a developer, I have pressure to keep my estimate down. I can give you a guaranteed date with few problems, <i>but</i> the project is going to end up more time-consuming than what another developer is going to estimate.<p>The good news is that I will usually significantly beat my estimates under this system. However, I will then be accused of padding my estimates and will be given more aggressive targets, some of which I will miss.<p>The best way to combat this is to give me a team that has worked together on multiple projects within the domain, and account for changes and ambiguities as part of the process.
dlitzover 11 years ago
The problem is that people try to eliminate uncertainty instead of trying to manage it effectively. If you&#x27;re trying to make estimates with more than order-of-magnitude precision, then you&#x27;re probably doing something wrong.<p>If we drove cars like we develop software, we would pre-calculate a list of instructions, set a timer, and then execute those instructions without regard to what&#x27;s actually happening on the road. With practice, you could probably get better at making those lists of instructions, but why bother? The general approach is just ridiculous.<p>Decades of experience have shown that there is enough inherent uncertainty in software development that trying to plan everything from the start just doesn&#x27;t have a high success rate. Even if you know everything that has to be done <i>today</i> to get the job done, your environment will change, and your stakeholders will change their minds. What good is software that perfectly solves the problem you had two years ago?<p>Once you dig through all of the buzzwords, &quot;Agile software development&quot; is simply about applying closed-loop control theory to software development: You structure your project to provide high visibility and to allow frequent changes in direction, then you iterate and make adjustments until the result is satisfactory.<p>Everything else generates unnecessary risks that somebody ends up paying for.
chris_mahanover 11 years ago
Because management looks at you funny when you say something simple will take 4 months. Then they lie and say that it couldn&#x27;t possibly take that long. And the reason they lie is because there&#x27;s no negative to them tying to you. Their job is to get you to go faster, and they are allowed to lie as part of their job, if it makes you go faster. The reality is that it doesn&#x27;t make people go faster. It makes people leave faster. It makes people give up. Never give an estimate to management. Estimating is their job, as they control the inputs to production. If you give an estimate, they will pressure you to meet it, no matter how unreasonable it later turns out to be. That also makes people want to leave.
评论 #6820686 未加载
评论 #6820775 未加载
评论 #6820776 未加载
wpietriover 11 years ago
I love this post; it conveys the feel of the experience so well.<p>One of my big aha moments about estimation was a bit in McConnell&#x27;s <i>Rapid Development</i>. He pointed out that most estimates get made with executives pressuring for short numbers. When you iterate a few times with that, you end up with the smallest number that developers can&#x27;t absolutely prove is impossible.<p>If you draw out a bell curve of probable completion dates, this is basically the same as picking one far to the left, so you have a 95-99% chance of being late. But somehow, executives are still surprised when their totally biased approach yields the numbers they liked, not the numbers they needed. All the estimation effort was pure waste; our time would have been just as well spent making cotton-candy raincoats.<p>I now have done a few projects with little to no estimation, and it has gone much better. I have a hard time now seeing why we ever bothered.
评论 #6821369 未加载
评论 #6820869 未加载
rdtscover 11 years ago
Good points in the article.<p>You can think of it this way. A coast line is a fractal line. As you zoom in its length gets bigger and bigger seemingly. From the top level on the map it looks fairly straight.<p>Related to estimates. Programmers have and operate with idealized mental models. A FIFO queue works kind of like this (&quot;&#x2F;closes eyes and sees a line of people lining up at the store&quot;), a tree traversal looks like this (&quot;&#x2F;closes eyes sees a red cursor move down a tree drawn with blue nodes on an white board&quot;). Same with estimates. How long will this take? (&quot;&#x2F;closes eyes and imagines an idealized sequence of events that will lead from now till project completion -- use this library, develop that API, test a little bit here, done... 2 weeks&quot;).<p>The problem is, zooming in is hard. &quot;Oh this library we are about to use actually doesn&#x27;t implement these corner cases&quot;. So now we are spending 3 days patching it. Oh, while working on this project, a critical support ticket comes from a customer. And then testing reveals a fundamental flaw in our API design. Re-write a huge chunk and repeat.<p>Some developers and managers just use heuristics. They do the mental estimate then x2 or x3.<p>^ All the above is true if the developer is everyone is honest and trusts each other. As other posts wrote, that is not always the case.<p>Then it is a more complicated game. The main question to ask then is &quot;What is the punishment for overestimating vs the punishment for underestimating?&quot;.<p>Have people been fired for underestimating? No, ok underestimate. Have people been fired for missing deadlines? Ok then overestimate.<p>You can even play this game with yourself. What kind of deadlines do you set for yourself and how to you handle setting a too short or too long of a deadline? Do you get better with time at setting deadlines? If no, why not?
评论 #6821217 未加载
nahnameover 11 years ago
Imagine you are going on a hike to the top of a mountain. Countless paths exist between you and your destination. Most of these are dead ends. Every dead end forces you to backtrack, sometimes all the way to the beginning.<p>Software is a lot like that.
评论 #6820701 未加载
评论 #6820639 未加载
评论 #6820647 未加载
pitchupsover 11 years ago
This post was originally an answer on Quora to the question posed in the title [1]. The question has so far received 222 answers - some of them arguably better, though not as popular as this one.<p>[1] <a href="http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3" rel="nofollow">http:&#x2F;&#x2F;www.quora.com&#x2F;Engineering-Management&#x2F;Why-are-software...</a>
评论 #6820951 未加载
tmoertelover 11 years ago
Software-development estimates are regularly off by a large margin for two reasons. First, the problem is inherently hard. Second, social and business pressures bias the estimates downward.<p>Why is the problem inherently hard? To see why, let&#x27;s imagine that the All-Knowing Fairy Godmother of Software Estimation descends from the heavens and lends to us her magic estimating function <i>F</i> that, applied to any software project <i>S</i>, will tell us exactly how much time and money our preferred software team will consume to implement <i>S</i>. Don&#x27;t worry about how <i>F</i> works, just believe that it does. (Okay, okay. Let&#x27;s just say that <i>F</i> peers into a parallel universe in which our team has <i>already</i> implemented a software system line-for-line identical to <i>S</i>, and it just observes how much time and money were actually consumed in that universe. Anyway...)<p>Now that we have the magic <i>F</i>, our problem is easy, right? Nope. The real problem is that we don&#x27;t know what <i>S</i> is. All we actually know is that our <i>S</i>, whatever it ends up being, must satisfy some set of fuzzy constraints <i>C</i> (commonly called &quot;software requirements&quot;).<p>In truth, there are a countless number of possible values for <i>S</i>. In other words, <i>S</i> is a random variable, a mapping that ascribes a probability to each of the possible software systems that we could build to satisfy <i>C</i>. Therefore, our best estimate, even with the perfect estimating function <i>F</i>, is itself a random variable. In other words, it&#x27;s not an estimate but a distribution of estimates.<p>See how fun this is getting?<p>But, wait, it gets funner. That&#x27;s because people in the business world don&#x27;t want a distribution of possibilities. They want a budget, a date on the calendar. So we must squeeze point estimates out of the true distribution. (And, remember, we don&#x27;t even know what the true distribution is!)<p>That&#x27;s where the second reason kicks in. Let&#x27;s just think about the distribution of possible budgets for our distribution of possible values of <i>S</i>. Because <i>S</i> can range from &quot;the simplest thing that could possibly satisfy <i>C</i>&quot; to &quot;the most insanely complex thing that a frighteningly gifted salesperson for an enterprise consulting firm could get our CIO to throw money at,&quot; that distribution is going to be w-i-d-e. From <i>X</i> to 10<i>X</i> wide.<p>So if we&#x27;re the folks tasked with coming up with those point estimates, we could plausibly estimate <i>X</i> on the low end, or 10<i>X</i> on the high end, or anything in between. Guess which estimates are going to get us the most push-back from the higher-ups?<p>Now, we&#x27;re swell guys and all, and we want to do a good job with our estimates. No question. But, still... We&#x27;re human. If we think that giving a higher-end estimate is going to make us unpopular with the higher-ups, maybe we&#x27;ll estimate a little lower. And when we get push-back on <i>that</i> estimate, maybe we&#x27;ll &quot;take another look at the numbers&quot; to see if we &quot;missed any opportunities.&quot;<p>And that&#x27;s the old one-two. We start with a hard, fuzzy problem and then add to it the pressure to deliver only feel-good solutions. The result: estimates that are often way low.
评论 #6821714 未加载
评论 #6823959 未加载
评论 #6822583 未加载
评论 #6822196 未加载
评论 #6824042 未加载
评论 #6822947 未加载
damon_cover 11 years ago
<a href="http://coding.abel.nu/2012/06/programmer-time-translation-table/" rel="nofollow">http:&#x2F;&#x2F;coding.abel.nu&#x2F;2012&#x2F;06&#x2F;programmer-time-translation-ta...</a><p>I occasionally just paste this link with no explaination at the end of emails containing time estimates.
swansonover 11 years ago
Most people would agree that practice makes perfect, right? I think a big issue with software estimation is that it is hard to get practice. I&#x27;d done full project estimates for 4-6 projects in 3 years of working professionally. Compared to the amount of practice I have writing code, this is nothing. How can I ever hope to get good at something if I only do it once every 3-6 months and it might take 2 years to get feedback on if my final number was close to the actual cost? And unlike other skills, I can&#x27;t practice on my own or take a course (I&#x27;ve never seen an open source project that did round-trip estimates, maybe that&#x27;s something to try out...)<p>Another issue is when you have an &quot;indirect estimate&quot; - basically I will estimate the work, but someone else is the one that ends up doing the project. If you aren&#x27;t careful to consider who will be doing the work, you might estimate too low (if you are an expert and the work is done by a bunch of new hires).<p>And none of this even touches on misinterpreting client demands, scope creep, dev team turn-over, or often neglected timesinks like documentation and meetings.
jl6over 11 years ago
Kept waiting for the punchline where the friend has moved to Las Vegas and a total replan is required.
评论 #6820648 未加载
评论 #6822420 未加载
reticulatedover 11 years ago
The single biggest mistake in the example is giving an estimate for the whole project without knowing team velocity. He tried to plan everything up-front and committed to a completion date, strongly setting delivery expectations.<p>An Agile approach to this walk would have managed the expected target date much better and improved team morale by not overstretching each day (&quot;sprint&quot;).<p>Lots of people think they know (and implement) Agile. I did, until a course I took about a year ago where I learnt skipping seemingly unimportant bits (measuring velocity, sprint retrospectives, etc.) bring the whole process crashing down.
评论 #6820857 未加载
pjmorrisover 11 years ago
I just had an estimate&#x2F;actual conversation that went like this: I think it will take me X time. Ok, but I want it done in .5 X time. Ok, I&#x27;ll try to get it done in .5 X time. I finish it in X time.<p>Is it a missed estimate? That depends on who answers.
评论 #6820885 未加载
pasbesoinover 11 years ago
Years ago, I was introduced to the (simplistic) dual concepts of profit centers and cost centers.<p>To many in Management and accounting (and with varying degrees of pointy-haired-ness), profit centers &quot;make money&quot; while cost centers &quot;spend&#x2F;burn&#x2F;&quot;waste&quot; money.<p>The sun shines on the former, while the inquisition perpetually stalks the latter.<p>Systems and systems software are often seen as a cost center. There is constant pressure to &quot;control&quot; these costs and to do more with less.<p>People are required to be over-optimistic in their communication while at the same time overly pessimistic (&quot;frugal&quot;) in their resource allocation. Note the use of the word &quot;pessimism&quot;. It is not so much a matter of &quot;optimisim&quot; thinking that &quot;we can get it done with less&quot;; rather, it is the pessimism of &quot;we can&#x27;t afford that&quot;.<p>Much of my professional life has been spent in big, &quot;conservative&quot; (cough), risk-averse organizations. I&#x27;m sure things are to some degree different elsewhere -- some <i>degree</i>.<p>Nonetheless, it&#x27;s worth keeping in mind this (simplistic, and to varying degrees counter-productive) concept of &quot;profit centers&quot; and &quot;cost centers&quot;. And if you are working for the latter, expect to be squeezed into ever more unrealistic positions.<p>It&#x27;s something the seasoned professional stays attuned to. There will always be some squeezing; when it starts to worsen and become excessive, it&#x27;s time to go. Your personal solution, as a &quot;simple&quot; employee, is to find another organization -- the sooner, the better.
avenger123over 11 years ago
I have found that providing estimates within a range is the most reasonable approach.<p>The range is usually between &quot;this is the likely amount of time with everything going as it should&quot; and &quot;this is the worst case scenario time with all that can go wrong&quot;.<p>It&#x27;s a pretty broad definition between the two but I find it gives clients a sense of the scope of the project. The minimum time does include some padding to include all the usual likely overruns (testing, requirements gathering, etc.) but not too much.<p>The worst case time better really be worst case as I provide clients the expectation that it should not take longer than this.<p>I find that usually I will end up somewhere in the middle of the estimate and the client is still happy since they didn&#x27;t hit the worst case scenario.<p>I find that this usually tends to be relatively effective even if as a rule of thumb the worst case time is 3-4x the minimum time.<p>Of course, there is still a lot of analysis done to come up with this range and there is a lot of discussion with the client to help them understand the details on why and how it could go.<p>At the end of the day, communication is king. I find that educating clients about the complexities of the process always helps to gain trust.
logicalleeover 11 years ago
Forgive my username, there is nothing logical about this.<p>It&#x27;s because estimates are really just a test of your imagination and skill. They&#x27;re a &quot;different game&quot; from delivering something. Here are some examples:<p>How long does it take you to add 1 + 1 together? The only correct amount of time is &quot;0 - no amount of time.&quot; But clearly that&#x27;s not true, is it?<p>How long would it take you to multiply 5 by 7? Well, zero. No amount of time - you know it &#x27;by heart&#x27;. It doesn&#x27;t take you any amount of time to multiply 5 by seven. Well, clearly, that&#x27;s not true is it?<p>How long would it take you to test whether 31337 is prime or not, by any means? Like, 1 second because Wolfram Alpha can tell me I bet. But clearly it wouldn&#x27;t take me ONE second, would it?<p>How long would it take you to write a function to test whether an integer less than 2^32 is prime or not, without having to be super-efficient about it? Well like 10 seconds. But, clearly that&#x27;s not true, is it?<p>And so on. How long does it take to put a twitter bootstrap page up? Like, 5 minutes.<p>How long does it take to...<p>You should be able to build an app that doesn&#x27;t crash and does what you&#x27;re trying to code in like a day.<p>You should be able to build something that is software you can launch with in like a week, as an MVP.<p>You should be able to replace someone else&#x27;s mature product with a reimplementation in like a month.<p>You should be able to build a scalable business that is ready for a series A in like a year.<p>These things are not meant to be accurate, so much as show that you have imagination.
jconleyover 11 years ago
This McConnell book[1] is a must read on the subject. Generally developers just fail at estimating at a fine grained enough level and forget about all the ancillary tasks that take up a majority of a project&#x27;s time.<p>[1] <a href="http://www.amazon.com/gp/aw/d/0735605351" rel="nofollow">http:&#x2F;&#x2F;www.amazon.com&#x2F;gp&#x2F;aw&#x2F;d&#x2F;0735605351</a>
ChuckMcMover 11 years ago
I enjoyed reading this the first time around. I purposely illustrates the complexity of software and perhaps inadvertently illustrates the challenge of getting schedules from inexperienced teams. In rebuttal, had they walked from San Francisco to LA along any freeway they would have been done much closer to their predicted date. Which they would have known had they been experienced in walking back and forth to LA from the Bay Area.<p>The &quot;big&quot; message is that if you have <i>never done</i> something before, you have no idea how long it will take, even if you can describe what you are going to do pretty easily. Returning to the hike metaphor, this is why you need to listen to the cranky old guy saying &quot;walk along the roads, not the beach&quot; instead of the inexperienced folks saying &quot;Hey its just walking, and walking on the <i>beach</i> rocks! Walking along a road is boring and lame!&quot;
ssiddharthover 11 years ago
I admit it&#x27;s funny but if I showed this to a non-programmer friend, he&#x27;d be asking why I didn&#x27;t research my route better or start on an unknown trail with minimal planning.
评论 #6820721 未加载
codexover 11 years ago
To put it simply: software estimates are hard because nobody has made that particular bit software before. Why? Because software doesn&#x27;t rust. There is little need to exactly duplicate software which has already been written. Thus, most software is charting unknown territory.
praptakover 11 years ago
Expect to be told, halfway there, that the party has moved to Tijuana. After all you agreed to hike to the party and it would be unreasonable to expect of the host not to move the party when the weather changes.
smokey_the_bearover 11 years ago
We sometimes make white label geo apps for other companies. We&#x27;ve repeatedly had problems where our estimates were off by quite bit because we got data in incredibly bad formats from the customers. And not just once, every time they&#x27;d send us updated data it would be in a different format.<p>The first time or two it made us hate the customer, and feel like it wasn&#x27;t our fault. But then we started writing it into the bid, and telling the customer they could save money if they delivered conforming data. Hopefully we&#x27;ll be happier from here on out.
stevewilhelmover 11 years ago
To extend the analogy further: add the fact that you need to meet up with several other groups that are providing essential supplies and they are hiking from several different locations in the Central valley.<p>Some of the groups are showing up on time and are waiting for you, some are late, all won&#x27;t have all the supplies you need.<p>And to make it more realistic: half way through the hike, your friends call to say the lunch has been moved to San Diego and is now a formal dinner party at which you will need to wear tuxedos. And can you bring the Champagne as well?
systematicalover 11 years ago
After getting a number of my estimates wrong recently I was thinking about this question. While walking to work I determined a few things.<p>It&#x27;s hard to estimate something that is complex. If I am very confident the job can be completed in under an hour my assessment is very close to 100%. This is because something simple does not have a lot of variables and interacts with very few things. Things like fixing a display bug, a simple calculation, adding a print now button are all easy. Once you go beyond this it gets more difficult to determine how long something will take.<p>Business wants the estimate done quickly. Many businesses want estimates done fast. An accurate estimate for a complex job cannot be given fast. There has to be several rounds of back and fourth. Use-case scenarios need to be determined, which will open up even more questions. The underlying architecture to accomplish the feature also has to be scoped which will take time and usually we don&#x27;t get it right the first time we think about it<p>Some more reasons are, businesses want the job done quicker than is realistic. Businesses don&#x27;t know everything they want. They think they need stuff that they never end up using. Haven&#x27;t thoroughly thought out the feature or problem themselves and that uncertainty gets passed into the development phase more often than not. Business is not solely to blame though. Sometimes developers think a particular portion of their code will be simple when its not or difficult when it isn&#x27;t.<p>Basically the whole process is riddled with human error on both sides.
Zenstover 11 years ago
People are generaly optimists and with that anything in the future will be biased towards ideals, even planning for exceptions will bias towards a ideal.<p>The other factor is feature creep, if you find a project so well defined and set in stone then it would be fair to say it will have a better chance of finishing on time.<p>That is just the software side, then there is the hardware to run it and that opens up a whole new aspect of poetntual delays that will get leveridged at the project and when people say project behind involving software people will just focus on the software aspect and all other factors are buried.<p>Bugs and issues come from many factors and even suppliers of hardware can have bugs which can have a impact, design could have bugs and many aspects can have issues that impact the end result.<p>But it is impossible and silly to plan for every situation as whatever you plan for there will be an exception and you get a deminishing return, hence easier to have a area of time labeled contingency as a catch all. Best example of such exceptions would be say an earthquake killing your entire development team, that can and has happened and at the same time is not something you plan for. Partialy why we have insurance. Though you will find it very hard to impossible to get insurace again software development delays beyond life&#x2F;death of parties involved, though that will not chance the delay into a non-delay, mearly compensate.<p>With all this Engineers have for many lifetimes gone with the engineering factor or whatever you think it will take, muliply that by 2-3 to counter optimisim. But that does not help feture creep and anything added to the design after code has started is creep.
pjungwirover 11 years ago
I loved the article, but I was hoping we&#x27;d get a reference to the Coastline Paradox[1]. Basically, since a coast is a fractal, its distance is infinite. The &quot;zoom&quot; that caused the very first delay could keep going, and going, and going.<p>Anyway, nice article!<p>[1] <a href="http://en.wikipedia.org/wiki/Coastline_paradox" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Coastline_paradox</a>
fayyazklover 11 years ago
That&#x27;s a very interesting sort of analogy. Among most of the discussed issues,<p>a) For one, giving enough time to come up with a project estimate is often rare. Usually people try to ask for those upfront.<p>b) Usually we try to add a general buffer for any unseen issues. However, the deeper you go and list tasks against time, the closer to realistic is the total.<p>c) Often it is just a customer giving a requirement needed at date x, or a management guy setting goal for a date y. When all you can do is to cut features but have to deliver by a given date.<p>d) No matter what we say, but at the back of our minds, we are not enough prepared to defend a timeline when giving it in the first place. Implementing feature x needs a week? gosh boss would say it should take a day. Latter it turns out the assumption was based upon a library which for just internal implementation reason (that you only discover upon learning it enough through actual code) is completely useless and it should actually be planned for 3 weeks at least.
sechastainover 11 years ago
The short answer is optimism and poor assumptions. The hiking analogy works well to illustrate this answer.<p>Everyone who has been a part of a software project knows about poor assumptions. From the start, you don&#x27;t have well-defined requirements. You don&#x27;t have a complete design. You don&#x27;t understand the consequences of decisions you have made or will make. Any estimate is doomed to fail in the face of all these poor assumptions.<p>Staggering a software project into smaller chunks goes a long way to controlling these poor assumptions and the impact to schedule and, more importantly, customer expectations.<p>The principles of the agile manifesto go a long way for mitigating the too common pie-in-the-sky wishful thinking that dominates software engineering. They work even better when the customer realizes they are a part of the system under development and its success - if they can keep that balanced with giving the development team the space to do what it is they do.
eftpotrmover 11 years ago
Well, yes, but also (stretching the analogy) how many times have we been asked for a schedule to an unnamed destination via unspecified waypoints and then told it&#x27;s too long and we need to make it shorter?<p>Devs make mistakes, sure, but as often as not in my experience it&#x27;s absurdly vague end user requirements married to unrealistic expectations.
sytelusover 11 years ago
Dumbing down analogies aside, you can look at software development as a graph of connected tasks with each task having some variance around when it would complete. This variance accumulates as taskw are completed and you move on to next nodes in the graph. When you complete the graph, you have large probability distribution about average ETA.<p>Most decision makers have to choose some number for ETA however because world does not understand probability distributions or variances. Most likely this has to be lower end of the number to get project sponsored or fend off the competition.<p>This is not unique to software development. Any projects that requires large connected graph of small task nodes would show same characteristics. For example, fighter jets, Boeing Dreamliner, space station etc etc.
judkover 11 years ago
Because the estimates are always BS, but teams get 2-3x slack before they are force to declare victory and launch whatever they have. The more over budget they get, the more they cut features (including QA and security details)
forgottenpaswrdover 11 years ago
I really love this article.<p>In practice a good strategy for companies is reduce unknown to a minimum, the Steve Jobs strategy, just focusing on very few products, with each having the less complexity possible(simplify and simplify).<p>Only focusing on very few products you could make perfection possible, estimates will be off, they always are when there is unknown, but at least completion will be finite (you will complete it!, which is number one issue with research work for example).<p>Sounds simple, but is really hard, leaving creative people on their own is dangerous for this reason, they could start new projects, not finishing anything.
评论 #6821036 未加载
dj-wonkover 11 years ago
Summary: The fractal dimension of a software project is roughly 2 or 3. :) <a href="https://en.wikipedia.org/wiki/Fractal_dimension" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fractal_dimension</a><p>Now, if you think about that metaphor for a while you may find value in seeing: (a) the metaphor doesn&#x27;t really fit intuitively because software projects are often charting new ground, not zooming in on a predefined complex problem (b) the metaphor is not too bad of an intuitive explanation -- you learn more about what is really needed as you get closer to the details.
11thEarlOfMarover 11 years ago
If you can suspend the obvious question of why are you hiking from San Francisco to LA in the first place, the general analogy holds quite well: With software development, you can not know how long it will take until you know exactly what you are building. You can not know exactly what you are building until you have fully described it. The act of describing it fully, precisely and with sufficient quality, is the act of coding.<p>Hence the completion estimate has to be continuously refined as the details of implementation are continuously refined.<p>Just like the slow zoom-in on the hike.
cuillevel3over 11 years ago
I think the calculation usually goes like that:<p><pre><code> * Take a day to come up with &quot;estimates&quot; for the project, can&#x27;t bill that time of course. * Sell fantasy gant chart to the customer. * Take 10-20% of the projects time away for &quot;project management&quot;. * Actually develop the software. * Fix &quot;bugs&quot; until customer goes silent. </code></pre> If you want good estimates you need to take estimates and project management more serious and get away from that waterfall methodology.
aufreak3over 11 years ago
Kahnemann and Tversky call it the &quot;planning fallacy&quot;.[1] the interesting bit is that the predictions are pessimistic when you get &quot;non-involved&quot; parties to estimate time to completion of the same task. Perhaps using a figure between self estimates and third party estimates may work?<p>[1] <a href="http://en.wikipedia.org/wiki/Planning_fallacy" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Planning_fallacy</a>
nathan_longover 11 years ago
In this analogy, you have a single destination; anything short of that is useless.<p>What about the agile idea that you deliver something incrementally useful with every sprint?<p>Obviously, some projects can&#x27;t be done that way. But if they can, it would mean 1) estimation can be done on a 2-week scale instead of maybe a 6-month one, and 2) they can start deriving benefit&#x2F;making profit from what you&#x27;ve built while you build the next thing.
gesmanover 11 years ago
Allowing for end-customer&#x27;s bad habits, such as delayed payments, real-time changing of specs and other unknowns that are fact of life for developer.
DigitalJackover 11 years ago
<a href="http://en.m.wikipedia.org/wiki/Planning_fallacy" rel="nofollow">http:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Planning_fallacy</a>
shitgooseover 11 years ago
If only they used one of those frameworks, that lift you off the ground and glide you towards the destination effortlessly, graciously pulled by flying pigs, there would be no delay. They would even have time for daily scrums. Always pick the right technology stack, guys!
cavilling_eliteover 11 years ago
The joke between us engineers at work is to estimate the project time, then multiply by pi.
评论 #6821146 未加载
csboweover 11 years ago
For me, a lot of underestimation is about motivation. I work best with looming deadlines. I <i>feel</i> like I will be motivated to work harder with a deadline that&#x27;s less realistic, even if that&#x27; not always true.
programminggeekover 11 years ago
One reason is as an industry we are terrible at planning. We do a very unthorough job of planning details or requirements. Then we allow for changes and new features mid project with no respect for budget or time.
judkover 11 years ago
That&#x27;s a great story for why the first project is slow. But next time, you say, OK, we can hike 10 miles a day, so it&#x27;s 60 days, and it <i>still</i> comes out 2-3x of budget. Why?
anupshindeover 11 years ago
Okay, I agreed (had no other choice) with management to not have less than 20% variance in my estimates.(read: negotiated-and-reduced estimates) as a part of our performance metrics.
评论 #6821915 未加载
reletover 11 years ago
For the same reason other estimates are off by a factor of 2-5, unless contractual penalties are agreed on. The cheapest contractor gets the job, and can adjust the estimates later.
clordover 11 years ago
I try to do my estimates (team size, man-days) in Big-O notation. Haven&#x27;t nailed how to do that yet, but it helps people understand that estimates are non-linear functions.
antonwinterover 11 years ago
when asked to estimate, i ask if the biz if they can also give me an estimate for meetings, UAT, changes, hiring resources, unscheduled downtime and scheduled downtime and historic data comparing previous project estimates to actuality. Its the only way to get closer to accurate.<p>The developers estimates generally are best case scenarios without any external or motivational factors included.
coldteaover 11 years ago
Here&#x27;s another question: &quot;Why are software feature requirement estimates regularly off and changing while in progress?&quot;
analog31over 11 years ago
Imagine estimating the time to complete a hike, and then being told that a bunch of children will be coming along.
brosco45over 11 years ago
Because software estimate is impossible, if it&#x27;s possible, then you are re-inventing the wheel.
lignuistover 11 years ago
Another reason is, that there are the first 90 percent and then there are the other 90 percent.
puppetmaster3over 11 years ago
As opposed to what? Marketing estimates? Scrum and such can be used by Marketing and others.
mpg33over 11 years ago
I just don&#x27;t know why people won&#x27;t arbitrarily add 2-3 more time on the estimate...
评论 #6820668 未加载
评论 #6820752 未加载
sz4kertoover 11 years ago
Because software developers, like most people, don&#x27;t like conflicts.
评论 #6820781 未加载
Shtirlicover 11 years ago
All estimates should be multiplied by Pi.
i_am_deadover 11 years ago
Only 2-3? Please tell me your secret!
mkramlichover 11 years ago
why? focus very closely on the following word:<p>estimate
habosaover 11 years ago
It&#x27;s the halting problem.
grownseedover 11 years ago
Here&#x27;s my experience with this problem. First, a number of people go meet the clients, often several times, to see what the client needs. Generally however, none of the people involved with actually building the product are ever involved in the meeting (because, from the mouth of the Boss, &quot;operations are too expensive&quot;), and in the unlikely event that they are, they&#x27;re essentially shut down because &quot;nobody really cares about the technical details at this point&quot;...<p>This is then followed by extremely loosely defined requirements being passed down to the technical people in hope of getting an estimate back. Technical people, especially experienced ones, know how this goes. First, you know you don&#x27;t have half the details you should have, even though you&#x27;ve most likely asked for them numerous times. But you know, &quot;all I need is an estimate&quot; says the sales guy (who in this case also happens to share the board, made solely of other sales related people). You already know you can&#x27;t win here, so you give a ballpark estimate considerably above what you imagine should be the real value, hoping it&#x27;ll cover your ass, but highlighting the fact that until more details are given, this is still a ballpark figure.<p>It doesn&#x27;t matter. The sales guy takes your estimate, shaves a third off of it, throws in a couple of bonus features in there (which are most likely of no use to the client), and makes it a hard estimate. When you point that out, you&#x27;re told not to worry and that it&#x27;s not your problem (spoiler alert: it very much is). So you write your specs down, or rather, you slap a few bullet point lists together with whatever little time you&#x27;re given (you&#x27;re expensive). This is given to the client as what both sides should abide by, despite you repeatedly saying that it&#x27;s a bad idea.<p>From that point, you realize that the time you&#x27;ve been given to achieve the work is, roll drums, not nearly enough. You can already see poorly defined features growing arms and legs: clients, and I can&#x27;t really blame them, will use any vague requirements to their advantage. You also realize that in order to do all the work and still meet the deadline (you still most likely won&#x27;t), you have to half-ass a bunch of the work. You can already imagine the support issues pouring in once the project is in production, and you see all those legacy projects constantly getting in the way of your new, poorly estimated work, thus slowing it down even further. You will also get blamed for all these issues that are cropping up from past projects, and this ties to the next point.<p>The best one of all, that thing that wasn&#x27;t your problem, suddenly is. You&#x27;ve somehow become responsible for the poor estimates you clearly said weren&#x27;t to be relied on. So you know, you better make an effort and fix that by, say, working extra hours here and there, like, every single day. You burn out and grow frustrated, which slows the work down even further. Even better is that your crazy work hours become an expectation, if you happen to finish a project on time this way, it&#x27;ll be used as &quot;See, no problem here, you got it done!&quot;, pat on the back and condescending compliments ensue.<p>So you realize you&#x27;re never given time to do decent work, that at the end of the day you&#x27;re better off not meeting deadlines, and that whatever happens, you&#x27;re always on the losing side.<p>I&#x27;m not saying this is the case in all companies, but I&#x27;ve also seen this far too often. On the very few occasions I had the chance to be the main point of contact with clients, projects were on time, clients were satisfied, and of course, some sales guy still slapped his name somewhere on there and got his bonus, but at least I got to do good work on reasonable deadlines.<p>I loathe most sales and marketing people, I often find they&#x27;re a completely unnecessary layer in product and value creation. It&#x27;s not that their position couldn&#x27;t be of value, but I don&#x27;t believe it can be if the money incentive is always more prevalent than the idea of good work done or happy people. As Henry Ford said, <i>&quot;A business that makes nothing but money is a poor business&quot;</i>.<p>Note: I&#x27;ve resigned from this job to work in research.
zupa-huover 11 years ago
thanks, was a great read!
paulhauggisover 11 years ago
My estimates are always off because management decides to constantly change requirements or didn&#x27;t have all of the requirements in the first place.
anotherfadjsover 11 years ago
Because no one wants to admit they still have to learn more about the system they are going to build.
评论 #6822276 未加载
lahwfover 11 years ago
Egos.