23 ms·

“Laws” of software estimation for complex work (2021)

• riwsky 4y ago
  Article not what you were hoping for? You probably wanted: https://en.m.wikipedia.org/wiki/List_of_eponymous_laws https://en.m.wikipedia.org/wiki/List_of_eponymous_laws Samples: Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter's law. Murphy’s law: Anything that can go wrong will go wrong. Cheops’ law: Nothing ever gets built on schedule or within budget. Parkinson’s law: Work expands so as to fill the time available for its completion. Brooks's law: Adding manpower to a late software project makes it later. Segal’s law: A man with a watch knows what time it is. A man with two watches is never sure. Vierordt's law: retrospectively, "short" intervals of time tend to be overestimated, and "long" intervals of time tend to be underestimated.
• japaneseminisub 4y ago
  There are some really great insights in here, particularly #7. We've used similar heuristics to identify if we are thinking roughly the same thing ie, if someones ballpark is wildly different from the norm its great to understand why. It could be that there is extra knowledge/context or that its unfamiliar. Both are valuable to understand. However I think the author is missing the point of estimates; to align multiple streams of business activity. Sure in the example they gave it seems like there are few dependencies but in the vast majority of situations there are. The launch month determines things like marketing activity, budgeting, hiring, internal/external training and so on. Its also useful for program directors/c-suite to identify critical paths across all streams and react accordingly. Estimates are a necessary evil, but should never be treated as a commitment
• quickthrower2 4y ago
  Hear! Hear! Good that someone has written this all out. I like that there is no solution/system offered. You don’t need points. That said an estimation style I like is “1h, 1d, 1w, 1m, or 1y”? Get a rough sizing. If the thing isn’t worth double or triple (oh no it took 2 days … I said 1 dammit!) then just don’t do it! Then stick that in a well buffered 1yr plan marked as “aspirational roadmap, not reality”
• tschellenbach 4y ago
  Estimation time. How many years and millions in budget does it take to write, secure, monitor and maintain a chat API that can be used by apps with hundreds of millions of users? I know the answer to this one :)
  • throwawaythekey 4y ago
    If you have the right team maybe 10M (to pay for the SaaS you bootstrapped off) and 1 year. If you have the wrong team then God help you.
• tschellenbach 4y ago
  This feels naive "Imposing estimates on others is a recipe for disaster". Estimates and deadlines are useful. It aligns everyone on what's required to be successful. They enable you to collaborate with other teams. If you can't estimate if something will take 3 months or 12 that's a problem.
  • atmavatar 4y ago
    When estimates come from the person/team doing the work, I might agree with you. The crux of "imposing estimates" is that said estimate is coming from a third party that has nothing to do with the work. Most often, it's someone who's trying to land a contract by promising a new feature by some deadline they just pulled out of thin air, knowing full well that actually delivering it is going to be someone else's problem. They got their commission, and no one's going to chew out the sales guy who landed a deal just because a few programmers whine about having to put in a few extra (unpaid if salary) hours.
• mbesto 4y ago
  > If you want buy-in, and better estimates, let the people that execute the work come up with the estimates. Then if the estimates are wrong, which they invariably will be, the team can only point their fingers at themselves. Weird advice. But if you truly want better estimates, just ask an experienced outsider: > "A similar finding is that experienced outsiders, who know less of the details, but who have relevant memory to draw upon, are often much less optimistic and much more accurate than the actual planners and implementers."[0] [0] - https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-fallacy https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-f...
• codazoda 4y ago
  This is good information but most of it is not actionable for the people building (I suppose it’s more a guide for the people who “threw it over the wall” this time). The one that is actionable seems like it could be interpreted wrong to me… “Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.” That may be true for estimates, but I seem to be most successful working in tiny pieces. That said, I believe you can hit a date or you can hit a feature set, but you cannot do both (a slight modification on the saying that also adds money to the mix). Throwing additional money at a problem doesn’t seem to scale very well, in my experience. It’s almost always best to hit a date and release what you’ve got. Hitting a feature set can drag and drag. In this articles case for more than a year.
  • rrmm 4y ago
    Although it wasn't explicitly prescribed, one action that was taken was quickly delivering some truth to the stakeholders. The customer was informed the original schedule wasn't possible and given an alternative (more realistic) timeline. I imagine many teams won't have that access or flexibility, so delivering truth may be first going back internal to the company and giving them a schedule, (and not just saying the original schedule won't work which in his story only elicited, "make it work").
  • wizofaus 4y ago
    Breaking huge tasks up is obviously necessary to make any real progress, regardless of whether you're trying to estimate anything - even if it was my job as an individual to do the whole huge task myself I'd want it in digestible chunks that I could feel I was making progress with, but more realistically it's going to be split between several developers anyway. Determining how to do that decomposition into subtasks that are genuinely independent (and ideally can be worked on in parallel) is obviously a key challenge of large-scale software development, and there almost never no "right" answers as to the best way of doing so. Interestingly if I've noticed anything is that once you split a huge task up in little ones and give each of those estimates, the total is often far bigger than you might have considered for the original task. And is more likely to be closer to the mark.
• lotophage 4y ago
  One of the most common mismatches between estimation and execution that I have encountered I phrase, "You never anticipate the unanticipated". During estimation people are generally optimistic and estimate assuming that they will not encounter any problems or issues along the way. That is rarely the case, and you can never assign an estimate of effort to them in advance since you don't know what those problems will be or how long they will take to resolve. You can assign a "buffer" of effort but this is just plucking numbers out of the air. I know that this is pretty obvious and basic stuff, but I'm amazed at how many people look at me like I'm crazy in planning meetings when I try to temper expectations when presented overly optimistic schedules.
  • KronisLV 4y ago
    > During estimation people are generally optimistic and estimate assuming that they will not encounter any problems or issues along the way. This is especially prevalent when people don't anticipate the overhead of the technical aspects needed to finish some business functionality. And yet, when my estimates are large people look at me odd and try to peer pressure me into not being an outlier. In the end, however, there's certainly a sort of multiplier for working with legacy code or overcomplicated systems.
  • doctor_eval 4y ago
    Yes, a closely related issue is domain knowledge (or lack thereof). Just when you think you’ve finished the job, some non negotiable domain rule comes along and ruins the rest of your month.
  • kqr 4y ago
    > but this is just plucking numbers out of the air. It doesn't have to be. You can learn to give estimations of the "there's a 90 % chance this will be done before date X" and then when you look back at your 50 last projects, roughly 45 of them indeed were done before your estimated 90th percentile point. Granted, the process will still look like plucking numbers out of the air, but the result will be more meaningful for planning than numbers actually plucked out of the air.
  • teeray 4y ago
• mhitza 4y ago
  Does anyone else on HN practice the multiply by 3 formula for estimates? I don't recall where I've come across it online first, but it has worked very reliably for me in the last 3+ years.
  • lotophage 4y ago
    Absolutely. I find it far more accurate and when it's not, it's better to underpromise and overdeliver than to overpromise and underdeliver.
  • Samon 4y ago
    One of my university professors advised "multiply your best-case-scenario estimate by Pi". It's still absolutely plucking numbers out of the air, but I've found it to be pretty reasonable over the last decade or so...
    • unnah 4y ago
      Using pi instead of 3 has the obvious advantage that your estimates are much more precise.
  • bruce511 4y ago
    I use 4 - double and double again. But yes, I subscribe to the approach of make your best guess, then multiply by 4.
  • jbay808 4y ago
    Depends on who I'm talking to. An estimate is not actually a number, it's a probability distribution. Few people want to hear that; they want one number to summarize it. But not everyone wants the same number. My team wants to know the mean; my manager needs to know where the cumulative distribution reaches 90%; and marketing needs to know where the cumulative distribution reaches 99%. In my experience, a developer's educated guess hits very close to the median completion time. Software task completion tends to be lognormally distributed, so to get the appropriate scaling factors, multiply that educated guess by 1.6, 5, or 10 respectively.
• asyncscrum 4y ago
  The most important takeaway here is that the customer is willing to negotiate timing and scope. The 12wk plan was actually 1yr and the author is still around to write this. If your colleagues claim the sky is falling because a software development timeline was wrong, they're not cut out for software development.
• jschveibinz 4y ago
  This is the classic reference book on software estimation; and yes, it still applies in 2022… Barry Boehm: https://en.m.wikipedia.org/wiki/Barry_Boehm https://en.m.wikipedia.org/wiki/Barry_Boehm “Software Engineering Economics” https://archive.org/details/softwareengineer0000boeh https://archive.org/details/softwareengineer0000boeh
• uptownfunk 4y ago
  Something I learned from a principal engineer- estimates from sde 1 multiply by at least 3x, from sde 2 and sde 3 multiple by at least 2x. And then add two-four weeks padding. And then pray.
  • guytv 4y ago
    If you really want to hit your goal, multiply by π, not by 3!
  • wizofaus 4y ago
    Have you tried applying that technique in an environment where you're expected to estimate every little bug fix? (some of which would often take less time to do than to agree on an estimate for!)
    • uptownfunk 4y ago
      Yes, rule still applies. But I work in an area where nothing is little. It’s not just the code change, I have to think about all the changes that come along with the code fix.
• skhavari 4y ago
  My experience on large projects aligns with the overall sentiment of this article. Except > 10. Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that. For very large systems, demystifying whats ahead can be a huge time saver. If you march towards a near term milestone without knowing whats around the corner you run the risk of having to go backwards after the unknown unknowns surface. The smallest of details may not be necessary but enough visibility to know you're headed down the right path is critical. None of this has anything to do with estimates.
  • jqcoffey 4y ago
    I think the author is describing analysis paralysis. They’re right in the sense that the most complicated work (in my XP) is often demystified with a bit of engineering over white boarding and whatifing.
• Joel_Mckay 4y ago
  "Program evaluation and review technique" https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.wikipedia.org/wiki/Program_evaluation_and_review_... Built by smart people... for smart people. =)
  • ramraj07 4y ago
    The issue at discussion here seems to be if you can even truly evaluate software work chunks accurately enough for it to matter..
    • Joel_Mckay 4y ago
      With enough experience it usually breaks down into the following temporal classifications: 1. 2 hours for trivial features 2. 2 days for normal features 3. 2 weeks for performant features 4. 2 months for known problems 5. 2 years for unknown problems 6. 2 decades for hard/currently-impossible problems 7. never (*note this is the default for people who can't tell the difference) Part of PERT, is placing redundancies with statistical upper bounds on estimated complexity. i.e. if the team or technology is unfeasible it is garbage collected. Many HR process people mistakenly assume every staff member is interchangeable/replaceable, as all tasks fall below class 4 in their mind. Cheers =)
      • djmips 4y ago
        Amazon believes all software developers are fungible.
        • Joel_Mckay 4y ago
          Agreed, the recruiter representing the hiring process at Amazon was/is very disrespectful indeed. Some like being unencumbered legally... so much so... a few more grand for the tax man make zero difference where you work. Amazon survives only as long as companies keep falling for the loss leader IT service models. Cloud-compatible is far wiser than a vendor lock-in that would make Oracle blush. Best of luck =)
• rqtwteye 4y ago
  My method is usually to ask a few people to make a quick guess, take the average and multiply by 5. Works like a charm but is unfortunately not "scientific" enough so people do story points and task breakdowns which then also take 5 times as much as estimated before they are really finished and buttoned up.
  • ramraj07 4y ago
    The factor of 5 seems to be a function of how bad the engineering team is at estimating - I would guess you have to come up with this factor for each team based on past experience.
    • rqtwteye 4y ago
      It’s also a function of the difficulty and unpredictability of the task and the overhead other functions like legal approval and mandatory documentation are causing.
• ramraj07 4y ago
  The root problem here seems to be that the CTO had no clue how long that feature would take to build; that seems like a criminal blunder for a Chief Technology Officer, who can’t estimate technology work! This seems like the pattern in general though - successful tech companies (though most “tech” companies today are not really that) only succeed if the person at the helm has the ability to tell tech from bullshit. Or you need to have a truly trustable confidant who you can fully trust on their opinions (which honestly is rare looks like). Without that ability you’re left to either guessing or depending on judgements of people beneath you who almost never have a fully aligned incentive to be honest either deliberately or just instinctively. If anything their incentives are often anticorrelated. I also think this is the issue with most pharma biotechs. gSK is (was?) run by a lipstick maker. What do you think their ability will be to tell if an IND is gonna actually work? You end up having to trust the CSO who might have more interest in making sure their drug gets to market than their eventual success.
  • alkonaut 4y ago
    Some might say "Does it matter how long it takes, if 12 weeks is the bid needed to land the deal?" To which my answer would be: yes. Just take down the sign and find something else to do if the best you can do to operate your business is a charade of moving goalposts and keeping a team in permanent crunch time.
• 2d8a875f-39a2-4 4y ago
  The CTO and CPO weren't estimating the time to build the feature, they were estimating the number they needed to win the business. Successfully - job done by the C-suite. The job of the author wasn't to build the feature in the X weeks, it was to manage the customer while the project completed in whatever time it took. He was successful too, even though he doesn't seem to realise that was his primary value-add. The customer didn't want or expect an X week delivery of specific scope, they wanted to sign on vague requirements that they could change as the project went along while keeping the vendor under pressure to deliver whatever thing they eventually found out that they wanted. All of the hand-wringing in the article about estimation misses the point entirely.
  • osigurdson 4y ago
    Very well stated. My conclusion is the same: It may not have been comfortable or unambiguous every step of the way but basically all stakeholders win in this story.
    • mlhpdx 4y ago
      Coming to “agreement” over a fiction isn’t okay. No amount of rationalization makes it “business”. More to the point, it is unnecessary. I hold there is harm here. A different skillset is needed to negotiate from truth (“we need to confer with our building teams to estimate the full project timeline”) and still be persuasive. It’s not more difficult, and these these skills are not rare. They don’t get used in some environments (not many, certainly not most) because of culture, and at the ultimate expense of the leaders that set it.
      • deleted 4y ago
        [deleted]
      • F_J_H 4y ago
        Maybe the company won the deal because the CTO and CPO said "yep - we can do that in 12 weeks" whereas the competitor said "we need to confer with our building teams to estimate the full project timeline" and promptly lost the deal...
• chester_the_dog 4y ago
  I would add: "It is natural for projects to appear to progress quickly at the beginning of the development cycle, since developers will seek out assignments that they understand. At some point there will be assignments that are more challenging, that are outside the primary expertise of the developers, or that take coordination with other teams. It is important for the long-term success of the project that developers not play games related to this, and specifically not to cherry-pick easier assignments to make themselves look good".
• fnordpiglet 4y ago
  In software engineering you generally have a complex dependency graph to complete something that’s largely unknowable and each edge is a random variable with a high variability skewing right. If you take the joint probability that any specific and precise date is in fact accurate, it’s effectively zero and has a long tail in the “later” direction. However management often confuses precision for accuracy. In fact, not just management - but humans do. A precisely articulated anything, no matter how much it’s caveated, is taken as a fact. It’s precise. You can measure it. To a human that feels accurate. We feel disappointed when it’s not accurate. Even when we were warned. This then gets into the discussion of how to estimate better. Holding the construction above to be true for any effort of any complexity that’s futile. The way I lead software is I keep a tight view of “could we do better now” and “are we doing the right next thing,” and if we learn we made a mistake we suck it up, fix it if we can, and then keep rolling forward. I give out precise estimates when asked and don’t tell anyone on the team. When we fail to meet those estimates I tell my story of precision and accuracy and get back to work. At some point things work well enough that the next step isn’t worth it given how long it’s taken and we are done. Seems to work well, yields good products, executes fast, and as long as I have a thick skin for being grilled on my inaccurate yet precise estimates its less stressful than the alternatives I’ve seen.
  • doctor_eval 4y ago
    This is such a great précis of estimation, which I try to avoid at all costs but which people insist on me making. And like you I keep them from my team. The only real problem is if, regardless of having a thick skin, you work for people who have little experience in the field and value planning over actual delivery. In my experience you are then well screwed.
    • gitfan86 4y ago
      I agree. The only solution that I have found for this problem is to take advantage of their ignorance and tell them things like "we need 2 weeks to do a hardening Sprint to protect from zero days" then you can do whatever you need to do those weeks and also upgrade a few packages.
  • 4y ago
• cpitman 4y ago
  #1, estimates have no impact on the time it will take to complete, is not generally true. Underestimating tends to significantly increase the amount of time a project will take, since the team gets pulled in to constant fire drills, rescoping, etc to try to figure out why they are behind schedule and how to get back on schedule. Overestimating tends towards the project taking longer because less pressure allows scope creep (ie Parkinson's Law).
  • kqr 4y ago
    I think #1 should be read "whatever work ends up being done takes the time it takes, not influenced by the estimate" which is true. What you're saying is "the estimate influences what work ends up being done" which is also true. In other words, there's no conflict there, just conditioning on different things.
    • TeMPOraL 4y ago
      I think GP's point is a bit different: that different estimates will result in different type and different amount of work being done for the same deliverable. This is well-known when you've overestimated - c.f. the Parkinson's law GP mentions - but they also have a good point about underestimates, which is something I haven't thought of this way. Consider an imaginary deliverable that should objectively (from God's point of view) take about 2 months to deliver, and different estimates being made and committed to in alternate realities: - 6 months - delivered near the end of those 6 months, possibly to above average quality, with surplus time organically divided between improvements elsewhere in the project, other tasks, research, slacking off, and general waste. - 2 months - delivered exactly on time, average quality, team fully focused on task. - 1.5 month - delivered exactly on time, average quality, team fully focused on task, if a little tired. - 1 month - delivered exactly on time, below-average quality, the team tired, demoralized by the anxiety and stress of meeting an unreasonable deadline. There's indeed little difference in work being done if the estimate is in range of ~1.5 months to 3 months. Above, Parkinson's law will noticeably kick in. Below, corners will be cut, people will burn out, and this unsustainable approach will start as soon as people realize the deadline is unrealistic - which may be at the very beginning.
• AlbertCory 4y ago
  The reason software estimation is hard is that estimation is hard. We all imagine that our problems are unique and other disciplines don't have them. Software estimation is so special that no one outside of CS can possibly contribute to it. In looking for software reasons why our estimates are bad, we ignore the glaring fact that estimates of any kind are often bad. But they are. The reasons are psychological biases, and they're brilliantly explained by Daniel Kahneman in Thinking Fast and Slow. In the chapter The Outside View he tells the difference between the Inside view and the Outside view. In the outside view, you know nothing about the case except the class that it belongs to. In the inside view you know, or think you know, a lot about this particular project. A short quote that summarizes it (his problem domain is a group writing a new textbook): ======================== The spectacular accuracy of the outside-view forecast in our problem was surely a fluke and should not count as evidence for the validity of the outside view. The argument for the outside-view should be made on general grounds: if the reference class is properly chosen, the outside-view will give an indication of where the ballpark is, and it may suggest, as it did in our case, that the inside-view forecasts are not even close to it. =========================== Somehow, I'm reminded of the blindness that amateur pilots have about fatal crashes. One actually said to me, "I've looked at all those crashes, and I'm confident I wouldn't have made those mistakes." So for software disasters, we tend to shudder and say, "Hopefully nothing that terrible will happen to us."
  • kqr 4y ago
    This is a good point. I've had much better luck estimating using the outside view, as Kahneman calls it (or willful ignorance, as Weisberg calls it). I think the problem is people in IT (including developers) don't have much statistical training. Taking the outside view and believing it requires faith in statistical principles. The people I meet in our field want to hear about nice narratives and specific examples, not reference-class generalisations and probability distributions.
    • AlbertCory 4y ago
      Well said. It's not that they can't provide estimates, it's that they don't want to. If you read RunSet's answer above: he really believes every project is unique, and you can't estimate anything about it. That's the attitude we have here: "I'm doing something that's never been done before!"
• primeblue 4y ago
• marshmallowmad 4y ago
  I don’t agree that trying to estimate things is bad as the author suggests. If you are perceptive and want to get better at it, then there’s a decent chance you will. Estimates also help us timebox work. They can help us give an objective view of when we should start exploring functionality tradeoffs. This article sounds like a lot of whining about not wanting to do something because it’s difficult. I will say I think that holding people to estimates is not fair because it doesn’t necessarily correlate with productivity/value added. When asked for estimates my general rule is: take a conservative estimate and double it.
  • fhd2 4y ago
    Let's call it what it is: Guessing. Guessing can be incredibly useful, and I've never seen an engineer or PM refuse to _guess_ (or "project"), because that implies they won't be held to it.
  • doctor_eval 4y ago
    But then there’s Hofstadter’s law: It always takes longer than you expect, even when you take into account Hofstadter's Law. https://en.m.wikipedia.org/wiki/Hofstadter%27s_law https://en.m.wikipedia.org/wiki/Hofstadter%27s_law
  • commandlinefan 4y ago
    > trying to estimate things is bad I've never, not once, in 30 years of developing software professionally, seen a feature request that was well defined enough to estimate to any level of accuracy. The definitions are always so vague that the answer could range from "this is already done" to "this is not possible". The hard part, and what takes the most time, is always working out exactly what they want - and that's what they want (and expect) an estimate of. "Estimate how long it's going to take you to figure out what exactly it is that I'm asking for."
• ohthehugemanate 4y ago
  Gah these articles and comment sections should come with a trigger warning for armchair speculation. I swear it's as frustrating as talking to flat earthers. Estimation is actually well understood in academic project management. There is (Nobel Prize winning!) research about what, actually, are the problems inherent to estimation, and how to produce specific and accurate estimates despite them. This academic field is almost 50 years old, and no one who complains about estimation in blog posts or comments is aware of it. Stop navel gazing and actually go READ about the subject. I know it's hard for us engineers to take in anything that doesn't come from StackExchange, but please try, BEFORE you write about your shitty experience with estimates and generalize to the entire problem space. Here's what the research says: - Humans are ALL bad at time estimation. Even the ones who consider themselves good at it, estimating tasks with which they are very familiar, "only" underestimate by 30% at best. - humans are pretty good at estimating non-time attributes of work, even those with a direct correlation to time. Like effort, complexity, or "cups of coffee." - if you estimate something with a time corellation (e.g. complexity) in a consistent way and measure the average throughput over time, you can very precisely and accurately estimate time to completion. This is the Law of Large Numbers, which is how casinos stay profitable when dealing with much more randomness than exists in software projects. It also makes your estimates include unexpected complexity, personal issues, illness, windows updates, etc. It's a statistical law. - the accuracy of average time estimates is proportional to the time left on the project. It runs opposite to the uncertainty of distant features. I.e. this method does not predict how much you can build in a week; you're better off with your relatively intimate knowledge of the feature at that point in time and a gut check. Rather it predicts how much you will build over 12 weeks, with extraordinary accuracy. - estimates are more.understandable when presented with a confidence interval, e.g. "the work as we understand it today will take 8 weeks, with a 95% confidence." What I HAVEN'T seen in the research, but which is undoubtedly true, is that most teams violate these fundamentals and then complain that estimates are useless. Asking your team to estimate in time units IS useless. Adding up those time estimates to create a long term plan is doubly useless. Cracking the whip on them when their estimates prove inaccurate is triply useless. And complaining about it on the Internet because you've never read any of the grown up work on the subject... well that's Hacker News.
  • 4y ago
• srazzaque 4y ago
  This is a great list. My thoughts on two of the points: > The biggest value in estimating isn’t the estimate but to check if there is common understanding. Wholeheartedly agree. The amount of extra detail I've captured out from the team, with wildly varying estimates on a particular work item, is astounding. It forces the team to articulate assumptions and dilineate between in-scope and out-of-scope details. This works especially well when stakeholders are in the same session, asking for why a button cannot be made blue in under 5 minutes. > Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that. Not sure. Perhaps breaking down tasks has a negligible effect on estimation accuracy. Maybe this is true for simple environments without complex dependencies across teams. But breaking down tasks provides (1) some certainty that you know a thing is achievable, (2) gives you a strong idea of what can be started immediately, and what can be run in parallel, and (3) hidden dependencies on other teams. This in turn leads to a better estimation. I have observed many failures when management assign a vaguely specified task (contrived example: "rewrite persistence layer to talk to new database") to a developer, that should really have been broken down into smaller tasks.
  • kqr 4y ago
    > It forces the team to articulate assumptions and dilineate between in-scope and out-of-scope details. The more general rule is to force people to put numbers on things. - Not "will this be expensive?" but "how many dollars do you think this would cost?" - Not "is this a big project?" but "how many calendar days will this take?" - Not "will we need a small amount of paint only?" but "how many litres of paint should we buy?" People very easily come to false agreement over vague terms and goals, but when the numbers come out it's revealed how different their opinions really are, and that's when the useful discussion about assumptions and theory start.
  • mjlawson 4y ago
    > But breaking down tasks provides (1) some certainty that you know a thing is achievable, (2) gives you a strong idea of what can be started immediately, and what can be run in parallel, and (3) hidden dependencies on other teams. This in turn leads to a better estimation. I very much agree. I think the key in the OP article is "to the smallest details." In order to truly know how to build something, you need to build it in the first place. Worse, you'll end up with a load of outdated documentation that will either be abandoned, or take up more developer time to update when it inevitably conflicts with what's produced. I tend to stop planning once I hit some "unknown horizon," meaning that any further planning is more or less built on well-intentioned speculation, or is bikeshedding at best. Past that, and I think you end up creating more problems for yourself.
• ResearchCode 4y ago
  Software estimation doesn't work for non-trivial tasks (and trivial ones should be automated, making them non-trivial). It's like asking a mathematician to "estimate" how long that theorem is going to take to get proven.
  • denton-scratch 4y ago
    If it's not proved, then it isn't a theorem, it's a conjecture.
    • eagleal 4y ago
      I think that was his point.
• iamasuperuser 4y ago
  Software estimates are unavoidable. I find this approach the best; rapidlyeatimate.com It works well to bypass anchoring and biasing by initially focusing on ‘divergent thinking’. It's as accurate as any I'm come across.
  • kqr 4y ago
    That seems to make the mistake of summing up the lower bounds to create a lower bound for the total time (and correspondingly sum the upper bounds to create an upper bound for the total time.) That yields a very unrealistic (as in not-relevant-for-reality) range for the total time. Am I misunderstanding something?
• kqr 4y ago
  A lot of people in this thread seem to have a gripe with > Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that. I think some of those comments signal that they misunderstand the point. There are two reasons to decompose a system before starting to build it: - To quickly eliminate solutions that are almost guaranteed not to work, and - To find consistency boundaries allowing you to structure work efficiently. These two things speed up development, they don't slow it down. What they have in common is that you don't need a very detailed decomposition to leverage the benefits. Usually decomposing into at most 5 components or fewer will get you there. What the point in the article talks about is decomposing into the smallest details trying to produce a detailed design containing finely grained subcomponents ahead of time. That, indeed, will take more time and may not even generate a better result, as the article says.
  • mojzu 4y ago
    I wouldn't disagree that decomposing a system in this way before implementation is a net positive, however I think different stake holders view plans like these very differently. If you discover partway through development that the library you planned to use for a feature will not work and as a result have to revisit your plan, then some stake holders see that as a failure or delivering late because to them the original plan was an iron-clad guarantee whereas to developers that's just an expected part of the process where not everything can be known ahead of time
    • kqr 4y ago
      Right, tracking success by the classic metric "percent of plan completed". That's a separate problem, I would think!
• torginus 4y ago
  The fundamental problem with this is almost all managers interface with programmers through Jira tasks/Gantt charts/Scrum sprints etc. The bad ones even one level down, but two levels down it's almost exclusively the only visible thing about devs.
• koonsolo 4y ago
  > What’s even more interesting is that even though the wrong estimate wasn’t my fault, it definitely was my problem now. As a 43yo developer, my advice is to push back on this. Make it clear from the first moment that it's their problem, not yours. You can do this in multiple ways, like saying "You seem to have gotten yourself into trouble. Maybe next time, come to talk to us first so you don't make this huge mistake again". Don't give in to their smooth management talk, keep your ground. They will try to let you solve the problem, but that's impossible. Let them solve their own mistake. If it's impossible to solve, well, it's a hard lesson for them. At least in Europe, there is a huge shortage of developers. That means your employer needs you more than you need your employer (plenty of other employers out there). So stand your ground and make sure the problem stays on their end, not yours. And keep reminding them that they have to come to you for proper estimates. You can already do this as a single developer. "This needs to be finished by Monday, can you make sure it is done?", "I'll do my best" (never promise!) When they do come to you for estimates, make sure you know the difference between estimates and deadlines, and assume they don't know the difference. Make sure nobody confuses your estimates for deadlines. Better yet, never let them see your estimates, and only give the deadlines.
  • willcipriano 4y ago
    Sometimes someone wants to push a mistake they made under the rug and in doing so they will throw your efforts under it as well. I'll solve your problem, but I'm doing it loud enough that your boss will be aware of the mistake as well. (unless you have gone to bat for me previously, generic manager with the 2.5% annual raise is going to be deaf with how loudly I solve his problem)
  • NAHWheatCracker 4y ago
    I completely agree with you, except that I'm currently going through a situation. The project manager has made a plan that a feature would be done by the end of the year. Two data scientists have been the only people working on it for the whole quarter. They said it's not going to be ready and they haven't even gotten it working on their local machines. The project manager turns to me and I concur with the data scientists. We had less than two weeks left when we talked, since everyone is taking time off for the holiday. I said I'm not going to work on it until it's ready and he's making out like I'm insubordinate and responsible. I honestly think I'm going to be fired. It could be a good thing. Maybe I can work somewhere where this sort of thing isn't tolerated. I think a great many workplaces are like this though. Pushing back, even a bit, can paint a target.
• randomsearch 4y ago
  The Startup way: make a list of features you want to build for your next "release" / deadline. Make that really minimal, what really matters to your users? Tell people you're doing the next "version" by that date, but don't go to far into specifics if you can. E.g. you can say you'll have feature x where there are variants of that feature x1/x2/x3 of increasing difficulty. If you need to, build prototypes of the features to get a feel for how difficult they may be. Then you've got a set of features you _think_ you can get done by the deadline. Write down the spec where folks can see it. The deadline should be say < 8 weeks away. No scope creep in that time. Stick to what you have. Then get to work. One rule: you will ship at that deadline. You can actually ship individual features beforehand if you do CD etc. You can use feature flags to hide the features for most users if you want to have them feel like a "version" has been released. But that deadline is set in stone and you do not move it (you can allow say a week slack to be reasonable, but probably keep that to yourself if you're a manager and only use it if you absolutely have to e.g. a key dev gets sick in the final week etc.) As the deadline approaches, things will go wrong. Keep the deadline. Cut the spec. Firstly, cut to simpler versions of the features. Second, start dropping features. Ship. People will be annoyed you haven't shipped feature Y that got dropped. Gauge the response. Now for your next "release", Y or Z is top of the list. After the deadline has passed, give folks a period to recover as you decide what's next, cut them some slack and then go again. This is the only answer I have to estimation.
  • fatnoah 4y ago
    > Then get to work. One rule: you will ship at that deadline. I think the happiest moment of the past 12 months for me was starting a job as a VP Eng and asking the CEO what they wanted most from the Engineering process. It was basically what you are saying. Pick dates and ship on those dates. Cut things if necessary, but regular shipment of improvements is the goal.
  • mr3martinis 4y ago
    There are two ways to approach the problem of inaccurate estimation: 1. set a date and trim scope to hit it 2. set a scope with an understanding that the ETA is truly estimated and subject to change Either way, stakeholders and the team have to fully understand and buy in on the approach. When the approach isn't clear or when you promise both scope and delivery date, it's a highway to the danger zone.
• chancer 4y ago
  This article feels like it comes from someone that has never worked with a high performing team. So many excuses as to why people cannot estimate.
  • rb666 4y ago
    If you think building a house and writing complex software are in any way similar, you simply do not work on complex software, nor manage teams in this sector.
    • deleted 4y ago
      [deleted]
• baq 4y ago
  One day I'll have to attempt the 'wanna bet?' estimation process, i.e. if I get an estimate from engineers, I'll ask them how much their own money they'll bet on it being true and crucially take it. This should really turn the game theory switch on in some folks which are usually resigned to assuming that any form of estimation is useless.
  • pjc50 4y ago
    Round 1: pad all answers. It's going to take a week to make that button blue. Your move?
    • forgotusername6 4y ago
      You ask multiple engineers and take the offer from someone who bet a large amount of money with a low estimate of time.
    • denton-scratch 4y ago
      All estimates get padded anyway. The estimator adds 10%, because he doesn't want to lowball himself. Then the boss adds another 10%, because all developers are optimists. Then the sales dude just pulls a number out of his fundamental orifice.
  • commandlinefan 4y ago
    > I'll ask them how much their own money they'll bet In a way, they always try that - when the estimates (that they were bullied into agreeing to, not that they came up with themselves) inevitably turn out to be too low, the developers are expected to start working for free (nights and weekends) to make them accurate.
• bazoom42 4y ago
  > It is our expectations on timelines that create a perception of late delivery. Important point! I like to say it is not the delivery that is late, it is the deadline that is wrong. It doesn’t change reality if the customer expected the delivery earlier, but it frames the cause better.
• sas224dbm 4y ago
  Some good stuff in there, but heard most of it in earlier publications. Reading Steve McConnell's "Software Estimation" covers a bunch of it, Cone of Uncertainty etc etc. Here's where i've seen estimation become accurate: 1) The people doing the work are estimating the work, and KNOW the software base they are estimating for. 2) Technology being used is not shifting considerably for the piece being estimated. 3) Processes being used to go from requirements elicitation to acceptance are not shifting dramatically for the new piece of work. You have to have probably 2 of these 3 to have any chance of reasonably accurate estimates. I've seen this work on a fairly large (1 MLOC C++) sonar system development. After a couple of 'late' releases, where those 3 premises were not true, estimation became better, and after 3 or 4 releases, teams were getting pretty accurate, such that customer trust went through the roof. If you don't have 2 or 3 of those ticked off, you'd better add in a bunch of padding, or get some risk $$ from the C-suite signed off.
• denton-scratch 4y ago
  > No matter what you do, your estimates will never be accurate. > When estimating, a different estimate usually means there is a conflicting understanding of what needs to happen. If all estimates are inaccurate (they are), then two estimates for the same job would be expected to differ, regardless of any conflicting understandings. The author's view seems to be that estimating is generally best not done. I had hoped there might be some tips on how to make better estimates, or how to use estimates better. Everyone hates estimating, because of the risk of being hoist by your own estimate; but sometimes estimates have to be made, and then it's best made by you, rather than by your boss or sales-dude. A long time ago I was taught Function Point Analysis. The job is broken down into "functions", which means something like deliverables: screens, reports, inputs, processes etc. Each function scores some number of points; you just add up the points. The number of days per point depends on the coder's velocity and the estimator's bias; given a history of estimates, the estimator's bias can be calculated, and the coder's history yields his velocity. There is also scope for fudge-factors, to account for e.g. complex processing. In addition to an estimate in days, this process also yields intelligence about your coders and your estimators. [Edit] Part of the goal of FPA was to facilitate making estimates based on just a functional spec, with no detailed design.
• madsbuch 4y ago
  i don't like estimates, but I do like reasonable deadlines.
• csours 4y ago
  This fits with my experience; I would include the following: What do the developers have to learn? New technology? New business domain? Are there new system interconnections? How many? How involved is the 'customer'? Who is the 'customer'? For B2B or enterprise software, do you have access to people who will actually be using your software? === A question I've been thinking about: Code, config, build and release pipelines, tests, documentation, etc are all the work product of software development, and those can be quantified (kind of). But what is the unit of work for software developers? I think it's the "try" - as in I had to try 100 different things to get this stupid thing to build. Those 100 things may have been in 2 logical work paths or 10 or 30. One path may have had 2 tries or 50. A path may have split into 2 or 3 or 10 other sub-paths.
• user3939382 4y ago
  Many years consulting for large custom systems for Fortune 500s etc: executives have budgets and they want to know how much they’re spending, what they’re getting, and when. They don’t want to hear about the complexities of software estimation. I manage the problem with waterfall: Step 1. Produce absolutely everything you know about your requirements in your own words and formats. Whatever you have, send it in. Don’t worry about structure (assuming no RFP). Step 2. I use that as a scope of work for a contract covering the Requirements Analysis. I can basically estimate how long the RA will take based on those client inputs, which costs me almost nothing (maybe 2-3 meetings) to collect. Client pays for the RA. 3. Develop RA. I now have a concrete scope of v1 product, a draft of the persistence model, key UI, etc, and can make a somewhat reliable delivery date. 4. RA used as the basis of the dev contract. Agile is nice when you’re building a technical product in house or, I guess when you meet execs willing to agree to that “we’ll see what the scope and cost is as we go” but I haven’t met them.
• xkcd1963 4y ago
  By taking this approach, the individual showed his willingness to think outside of the box and take initiative without involving his superiors. It demonstrates his resourcefulness, determination, and capability to make decisions independently. The individual took the risk of potentially facing consequences later on if his superiors did not approve of his actions. However, it was clearly a calculated risk as he had the support and permission of his clients to proceed with whatever necessary for the success of the project.
• borgchick 4y ago
  We use to jokingly say that whatever the estimate is, the actual time it takes is twice as long, and increase the unit. So if the estimate is 2 weeks, it's gonna take 4 months. Surprisingly, the latter is a more accurate estimate most of the time.