22 ms·

Tasking developers with creating detailed estimates is a waste of time (2020)

• willmadden 5y ago
  It depends on how they estimate and how familiar they are with the code base. I know developers that have been nearly spot on consistently with modifications and maintenance work. The wildly inaccurate stuff seems to come from new work with loose definitions, manic developers, or situations where the work is billable hourly and outsourced. Sometimes it's good to have an old, graybeard developer on the team :).
• tupac_speedrap 5y ago
  On my current project we don't estimate. It might not be suitable for most projects but we just pick up tickets off the kanban board instead of wasting days every month arguing whether a ticket is a '5' or an '8' we just do the work that needs doing the most.
  • ponyous 5y ago
    This works well with senior developers with the same background as people that drive the business decisions, otherwise developer's understanding can be completely different. I think you need to discuss everything that is going to be done as part of a ticket anyways. Asking at the end "Is everyone ready for estimation? 3, 2, 1 go" takes an extra minute.
    • haakonhr 5y ago
      We do this sometimes and it is interesting to see how big the range can be. The motivated, new developer gives a 3 for reasons while the senior who's been burned by the big ball of mud too many times gives a 13 and the PO somehow thinks this means it is an 8.. For me it is a wasted minute (times tickets), but you gotta pick your battles.
      • ponyous 5y ago
        True. Our default is to go for higher estimation especially coming from a senior. 13 should be broken down tho.
        • Oddskar 5y ago
          I know that this is a commonly held belief, but: why does it need to be broken down? Can a 13 not just be a 13?
          • ponyous 5y ago
            In our system it implies a major piece of work that can almost always be split down into multiple tickets that can usually be worked on in parallel. 2nd Splitting it in smaller parts forces you to examine all the parts and inner workings. Sometimes you will realise entirely different solution is needed, sometimes that there is an api call that will incur costs… and some of these things definitely have to be communicated to stakeholder, ideally before you spend significant times in development.
      • 3np 5y ago
        Last time I was in a team that did this, it was pretty useful. A wide range would spark a brief discussion (the senior would bring up the points that the junior is missing - yay knowledge sharing) and high estimates would usually result in breaking down. The key is to keep it short, if need be timebox.
        • throwanem 5y ago
          That, and time estimates are output. Estimate by story points or T-shirt size, track how long tasks take to complete, and you can trivially derive a mapping from one to the other. Revise during implementation, too, if need be. Something that was estimated as a 3 and turns out to be a 1 gets re-pointed, and vice versa. This helps in all kinds of ways. Engineers don't have to think about time when estimating, which tends to make estimates freer and thus more accurate. PMs/POs don't have to deal with too much uncertainty, because the distribution of time to completion over a given estimate is right there. It's easier to know how much can fit into a given sprint, and as soon as all the tickets in a given epic are pointed, you can know about how long the epic will take to get done. Engineer time remains nonfungible, of course, but if the team is well balanced that seems to average out, and I don't (yet) know a better method of squaring a team's need for looseness with an organization's need for legibility.
    • tiagogm 5y ago
      You don't need to discuss everything. The the oh-so-common 2 hour+ full team meeting scoping session, where half the team dosen't care what the other half is talking about since it's irrelevant to them - it tires everyone out and produces very little value for the impression of "we're now aligned". Things only need to discussed if, when and only by as many people as required, everything else can be followed up later, it's really okay. Personally, I've always found things like 3 amigos to be much more time effective.
    • pydry 5y ago
      It works well with junior developers too. The problem isn't really seniority or juniority it's that doing this usually requires buy in all the way up to the CEO. If it doesn't then the CEO pressures the CTO for estimates, the CTO badgers the middle manager for estimates, the middle manager badgers the project manager on your team for estimates and he comes nervously to you asking if you could please give him something resembling a date while he nervously wonders how much to pad it. Each one has their asses on the line for the date. You can be as "agile" as you like on a team but this wave of estimate badgering reliably turns on the waterfall every time.
  • bencollier49 5y ago
    The 5s and 8s are like the Holy Grail. The Grail isn't the point - the quest is.
    • magicalhippo 5y ago
      We don't do detailed estimates, but we do some estimation. Often the discussion around the estimation leads to a change in the task, which drastically impacts the estimate. That is, by thinking about how to solve it, in order to estimate time taken, one can come up with alternatives which might achieve the same or a similar goal with less work involved. Maybe the customer doesn't need such a bespoke solution after all? Maybe we can ask the customer if a slightly different solution is suitable? For example, recently a customer asked if we could make a new web API that they could query for some data. While estimating the point was brought up that just transmitting a xml/json file with the data once a day might be just as good and less error prone for the customer. After all the underlying data doesn't change more than once a day anyway. So we ask the customer and once they think about it they agree it's a better solution all around. So they get what they wanted for a much lower cost, and we didn't have to commit a lot of resources to make a new API.
• Mountain_Skies 5y ago
  >There is back-and-forth as the estimates are questioned for being too high, almost never for being too low. I believe this has only happened to me once in my career. My employer had recently switched from flat rate project bids to time and materials. A data transformation project that looked like it would take five or six weeks turned out to have repetitive tasks that could be automated easily. My estimate of three days, which was already padded, wasn't appreciated by the PM what wanted a month of revenue. After being told several times to account for contingencies and not budging much on my estimate, the project was taken from me and given to another engineer who gave the PM the estimate she wanted. While this was going on, I had already written the necessary code. My coworker had a month of mostly relaxed days as I turned the code over to him and he got busy finding ways to look like he was doing work for a month. Maybe I should have done that instead.
  • noduerme 5y ago
    You did the right thing. If it were a client, I would have said hey, I wrote this amazing way to automate your job and I'm going to save you half the time I estimated. Half being contingent on how much originality went into the automation process. If you just did away with 300 hours of work for yourself in one hour, charge 150 hours. [edit] How many hours they were expecting is also key here. [edit2] but you morally did the right thing, and your colleague who took the summer off is a jerk. Hopefully you spent the time doing something more useful than repetitive work, and that is a reward in itself.
  • siva7 5y ago
    Morally certainly the right thing, unfortunately morality isn't what keeps business and career afloat.
    • Mountain_Skies 5y ago
      I ended up quitting that job over a dispute on double billing clients. If they had changed my timesheet entries after I made them, I would never have known but they insisted that I enter incorrect inflated hours. They justified it as recovering PM time the client wasn't willing to pay for which only made me less willing to falsify my time. Scummy company but this was during the dot com bust and they did survive when many of our competitor's died.
• noduerme 5y ago
  >> ?+?+?+Contingency™=The Date™. I've always had a strong feeling that my strong feeling about when something will be done is fairly accurate. Decomposing that into ?+?+?+Contingency for the client tends to be the hard part.
  • mellavora 5y ago
    Reading a book where Tom Sheppard (former RAF pilot, solo desert adventurer) breaks down the fuel estimation process as: mpg * terrain factor * safety factor it's pretty important to him to get his estimates right, so he is rather serious about this. Assuming your 'gut feeling' is pretty accurate (I suspect it is), you could probably break it down into: - these components will take X days, - getting them to work together is an extra Y, - contingency factor is Z I honestly don't understand how your gut feeling could be accurate unless you had a well developed sense of those factors, or some similar breakdown of what it takes to deliver a project and where the complexities/unknowns are.
    • aurelianito 5y ago
      We humans work by analogy. Experienced people think, probably unconsciously, it is similar as these tasks that took about this time. No breakdown required.
    • noduerme 5y ago
      It's like any other skill you develop from watching something carefully enough times, long enough. I can tell if an edge in a graphic is off by one, two or three pixels without needing to measure it. Mechanics can look at a screw and know what size wrench, and whether it's metric or imperial. Estimating times and prices does involve juggling a lot of variables and potential for overrun or mission creep... but it's certainly not just true in the code world. The design world is worse because the deliverables are so much harder to nail down. If you play "price is right" enough times you just develop a feel for eyeballing it that tends to be accurate. In the end, the most sophisticated system in the world for estimating a project is a black box AI that's constantly adjusting its parameters and weights, and that's basically what an experienced brain does without breaking it down into steps. You can of course break it into steps, but they're all hypothetical and only you understand how one can be extended and another reduced to meet the same target. It's like cooking. Okay... yes, ingredients, preparation, bake time... you have to take each into account. It can be hazy when you're estimating 6 months or 8 months, because you're not sure how it will come together after the first 4. That's true, for something that large.
• Hokusai 5y ago
  > For many of us a dearly loved date has already been selected, which makes our estimation efforts really interesting as we endeavor to shove more and more "stuff" into that bag. The problem is not to ask for estimates, companies need to budget, plan hiring, and inform clients. The problem is that many companies do NOT ask for estimates but create delivery dates out of thin air. So, I agree that estimates are a waste of time if they are not used. But they should be used as are part of any reasonable-managed engineering project.
  • ed_elliott_asc 5y ago
    Estimates are only useful if accurate but to create accurate estimates is hard - my standard line is “if you want me to get a better estimate i need to spend about 1/4 of the time estimating to work - so if I think it will take a day, I should have spent a couple of hours on it, if I think it will take ten days then I need two and a half days to estimate it - do you want me to do that?”. Every.single.time - the answer comes back as “no, don’t worry, just a best guess” aka made up useless estimates which are invariably wrong.
    • bradleyjg 5y ago
      I don’t disagree but that probably means we as an industry need to figure out how to get better at this. It’s not unreasonable for stakeholders to want to have a rough idea of how long a project is going to last. Maybe this is something software engineering professors can research.
      • senko 5y ago
        > Maybe this is something software engineering professors can research. Good idea. We should also ask them how long that research will take so we can have a rough idea of how long we'll have to wait.
        • bradleyjg 5y ago
          AFAICT academics never have deadlines to produce anything specific. Sometimes they’ll have requirements to publish X papers in Y years, but never solve this problem by date certain. Which makes sense for open ended research projects, I don’t have any sympathy for a CEO complaining that no one can tell him how long to fully autonomous cars. It’s less fine for build me a website type projects.
• stronglikedan 5y ago
  I like doing detailed estimates, because it helps me decompose the problem. This gives me a chance to get a good understanding of the problem, and get up-front clarification from the customer on even the smallest details. The side benefit is that it also gives me an idea of how long the project will take, with regards to the knowns. Then I triple that as my estimate to cover the unknowns, with a bit of wiggle room to spare. Then I stick to my guns with management (a luxury, I'm aware), and the customer's expectations generally get set accordingly. So, while it may not be an exact estimate, I have an accurate understanding of the requirements up front, and the customer usually ends up happy on the back end.
  • haakonhr 5y ago
    I think this is key. I often struggle to communicate that estimating certain tasks essentially means starting them and that giving a proper estimate might require a day of work (or more), e.g. when getting familiar with a new API or working towards some performance criteria. However, this is rarely taken to heart so most of our estimates are more "if you actually want an estimate it will be essentially random from the top of my head", which satisfied the product owner for now and defers the dissatisfaction that comes when said estimate turns out to be inaccurate.
• ajsnigrutin 5y ago
  Just do an aproximate estimate, multiply by two, and add 30% ... it won't be enough anyway.
• rahoulb 5y ago
  Years ago, when I was working at a company, I did a detailed estimate of a large project. I broke it down into components and individual tasks, then put estimated hours against each one, then put it all into a giant spreadsheet, to track planned vs actual times. If I remember rightly, it totalled about three months of elapsed work time. And it took me over a week to compile the estimate. I also remember that I hit the predicted end date to within two days. But the interesting bit was each individual task was inaccurate - lots were wildly underestimated, balanced by those which were wildly overestimated. Stuff like things I thought would take a day taking 15 minutes, other things I thought would take an hour taking a week.
  • ThePhysicist 5y ago
    A relative error factor of 40 sounds quite high. I also often overestimate task complexity but not to that degree, except maybe in research-like projects. I think often these over-estimates are caused by tasks where you just know the requirement but not yet how to realize it. For example, estimating the requirement "setting up TLS certificates" might yield an estimate of one week if you have never done that before. After researching how to do it you might end up with one hour of work, e.g. because you learned that you can use ACME to auto-generate certificates. Does that sound right?
    • rahoulb 5y ago
      This was dev work - and generally when something goes over by that amount it's because my understanding of the requirements and the client's understanding of the requirements were very very different.
  • jpomykala 5y ago
    Years ago, I also needed to make an estimation, so I simply described which functionalities will be available in each week. I also added a 2 weeks margin to polish everything at the end of the planned deadline, and it worked great. The client was happy because he could see the progress every week, and I was happy because I was on time with everything. During the polishing phase, we were meeting every day to make sure everything is adjusted or fixed properly.
• brianmcc 5y ago
  My God I remember the days of coming up with estimates for like 40 tasks, each a few days, say, then "negotiating" with sales/PM where we could shave a day off here, a half day there. And lo and behold, we price for a 30 day project that ends up taking 50... So ridiculous.
  • OneTimePetes 5y ago
    And never once did they learn a thing from the told you so. Sales is ridiculously decoupled from all the chaos they cause in most companies. Must be a easy job, selling something a company can not offer and then not having bear responsibility if you can not deliver.
    • brianmcc 5y ago
      We did actually make some progress on this in one place - if sales wanted a 50 day project priced at 30 days they had to get the executive team to approve a discount rather than sell an artificially low estimate. Happily those days, for me, are long ago :-)
• lkrubner 5y ago
  In my essay "The worst project manager ever" I talk about some of these same flaws, but I also talk about the best project manager that I ever worked with, Sonia Bramwell, and I recount some of the lessons she taught me about great project management: http://www.smashcompany.com/business/the-worst-project-manager-ever http://www.smashcompany.com/business/the-worst-project-manag... About this: >There is back-and-forth as the estimates are questioned for being too high, almost never for being too low. Sonia did not allow us (the engineers) to talk to upper management, so she handled the translation herself. In some cases she was worried about macho engineers who competed on how fast they could do something: "I can do that in a day" "Oh yeah? Well, I can do that in 4 hours!" "Ha! You two suck! I can do it in 2 hours!" Perhaps Sonia's greatest ability was to figure out exactly how much each engineer tended to overestimate or underestimate tasks, and then to weight their answers accordingly. For the upper leadership, she was the only one who continuously offered accurate estimates of how long big new features would take.
  • tikhonj 5y ago
    > Sonia did not allow us (the engineers) to talk to upper management, so she handled the translation herself. In some cases she was worried about macho engineers who competed on how fast they could do something: That strikes me as incredibly condescending. Normal estimates and processes already do quite a bit to erode developer agency, and seems like this attitude just doubles down on that dynamic.
    • throwanem 5y ago
      It would have sounded that way to me, too, a decade or so ago. I've learned a lot since then about the internal politics of organizations, and these days for most purposes I'm quite happy to leave them in the hands of a skilled specialist when available.
    • Karawebnetwork 5y ago
      From that very same article: "There are moments when it is useful to have the engineers (or any kind of staff with specific skills) talk to upper management and talk to outside clients. But those discussions need to go through a specific process, they can not be allowed to happen randomly."
• bengale 5y ago
  It's surprising that developers and business people still haven't found a way to come together on this stuff and explain to each other why our views on estimates don't line up. At the end of the day a business is always going to need some sort of idea of what's being built and when it might be ready so that they can get a rough schedule together. No matter what games developers and project managers play with story points, or t-shirt sizes, or the myriad of other coping strategies they come up with, someone in the chain is going to try and map those to time scales. In my experience, a reasonably senior developer can give a rough estimate of how long something is going to take in any case that isn't a complete unknown, if they really can't then you need an investigation project and that can be given a set time. But for almost everything else you can roughly say if it's an hour, or a day, or a week, or month. As long as everyone accepts that sometimes that will be over, and sometime under. If its an hour that doesn't mean you can do eight of them in a work day, but it means you can prioritise work. That's the key I think, if you have a fixed date or a fairly fixed date, then it's often a good constraint. What you need to do is prioritise the work, and the only way you can do that is if you know that the things in your list could reasonably be done in that time. You can't have no estimates, and task three means your entire team needs to invent an AI or something stupid that will burn the whole timeline down. If you've put a rough estimate of a week on something and you're reaching the end of week two, it's a great time to reassess. What technical people often don't get told, or don't understand is that sometimes something is only valuable if it can be done in a certain time. The business might want a feature that could be done in a week, but have no interest in it if it'll take six months. If both sides can admit to their fears then it shouldn't really be too complex. Business is scared you'll get to the deadline and have 20% of the work done, with a good prioritised list they'll probably be happy if you're 80% of the way there. Developers are scared you'll hold it over them and berate them if their one day estimate becomes two days, but they probably know their one week estimate is bullshit and they just want to cover their ass a bit.
  • neurotrace 5y ago
    So incredibly true. I used to be staunchly in the "estimates are empty promises made by business people" camp. The last couple of years I've worked in an environment where both engineering and product understand that estimates are not created out of thin air and they have real consequences on both sides of the coin. Our estimates have become far more accurate not only because we all understand that they _are_ estimates but because engineering is able to creatively come up with solutions that meet the business needs, not just the outlined "requirements." Most importantly, any potential shifts in our estimates are communicated every week and we have built in float time to account for these shifts. We haven't missed an estimated date in over a year.
• diiq 5y ago
  This appears to be based on a strange assumption that developers' estimates can't take historical work into account, but dev managers' can; and that estimates coming from dev managers and based on historical work will not be questioned for being too high even in orgs where the devs' estimates will. I'm not sure the prescription given fits the disease described; it feels more like passing the problem on to a different role than actually changing the approach.
• ChrisMarshallNY 5y ago
  For myself, I have found that the more detailed an estimate, the more detailed an "up front" plan. This is a classic pattern, and techniques like Waterfall and TDD rely on it. It's an extremely good way to get the costs and plan formalized (critical, in many organizations). Further, with TDD, this allows a very detailed and complete test matrix to be established, so the end quality can be quite high. I worked this way for most of my career. One of the big reasons, is that I spent a lot of my career, writing software in support of hardware devices, and coordinating parallel development efforts was crucial. Lots of critical paths. Also, hardware people tend to be very "waterfall-y," so I was often never given a choice. As a result, we learned to give fairly accurate estimates, for pretty long-term projects. The main problem with this approach, is that it delivers yesterday's technology, tomorrow. By the time the project is released, no one wants it. Also, it's quite possible to deliver features and algorithms that aren't useful, inherently flawed, or actually detrimental to the user's workflow. Once it has been written into the lists, it is set in stone; even if it is found to be a mistake. After leaving my last job, I started experimenting with more flexible development methodologies. I think I've had some success[0]-[4], but the scope of the projects has been much more humble than my previous works (out of necessity). In the project that I'm developing now, there has been almost no "up front" plan at all, and no set schedule. I've been working on the frontend app (a native Swift iOS app) for over a year. The backend is a couple of servers that I wrote years ago. One has since become a standalone open-source initiative, run by a different team[5], and the other was one that I made as "practice," several years ago[6]. In developing the frontend, I created a TestFlight-ready app, almost immediately (I made my first TestFlight release about a month after I started coding). This has been a "running prototype," ever since. The entire team gets releases, quite quickly, and gives feedback and testing. Additionally, the app is continuously being vetted by Apple, so we are unlikely to have the "App Store Approval Brick Wall" problem. This has allowed the specification to "morph," throughout the life of the project. I have actually thrown away months' worth of code, as we have decided to pivot direction, many times, throughout the lifecycle. We're all very happy with where it's at, now. We are in the home stretch (but we still have at least a couple more months of work on the frontend app). It is almost entirely different from the original, unworkable, "idea man" concepts, that were presented to me, over a year ago. I've also been doing this for free. I can't imagine any company that wanted to make money, doing it this way. I would have been forced to deliver a crap hack, six months ago. [0] https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships... [1] https://littlegreenviper.com/miscellany/forensic-design-documentation https://littlegreenviper.com/miscellany/forensic-design-docu... [2] https://littlegreenviper.com/various/evolutionary-design-specification/ https://littlegreenviper.com/various/evolutionary-design-spe... [3] https://littlegreenviper.com/various/concrete-galoshes/ https://littlegreenviper.com/various/concrete-galoshes/ [4] https://littlegreenviper.com/various/testing-harness-vs-unit/ https://littlegreenviper.com/various/testing-harness-vs-unit... [5] https://bmlt.app https://bmlt.app [6] https://riftvalleysoftware.com/work/open-source-projects/#baobab https://riftvalleysoftware.com/work/open-source-projects/#ba...
• kenoyer130 5y ago
  The iron rule is the person doing the work also supplies the estimates, which are the only ones with any chance of getting them right. This article seems the developers have not been properly trained on how to give accurate estimates. https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
  • arthur_sav 5y ago
    And from my experience, one meeting with the PM asking how long will it take... is not going to cut it either. Until i really dig into the requirements and dependencies i will probably fall out of the estimate. The biggest bottleneck for me is usually other stakeholders.
  • lightbendover 5y ago
    I would strongly disagree and Joel offers no evidence in defense of that statement. I wouldn't expect junior employees to have a strong understanding of task complexity, their own ramp-up period, available resources, unforeseen impediments, the experience necessary to estimate accurately, etc.. Estimates are best done by the team as a whole as it is the only way to rely on everyone's collective judgment ("I don't think we need this requirement," "we are going to run into this problem," "this is similar to task X we completed 2 years ago"). If done in this manner, the process also serves as training opportunities for the more junior employees.
    • commandlinefan 5y ago
      I have read the Joel link, but I actually didn't need to read it to know what it was going to say because it says the same thing every "you just need to learn how to estimate" article ever says: "First, write down everything you're going to do. Second, write down how long each of those things will take. Third, add them all up and voila, you have a 100% accurate estimate! Easy!"
• harry8 5y ago
  An estimate is usually the sum of a bunch of smaller estimates. Those estimates have a probability distribution that is asymmetric. While sometimes they can be quicker than anticipated, the lowest they can go is zero (turns out we don't need it, cut it) and that kind of thing is relatively less common than a blowout the other way. Those blowouts are uncapped, while zero time is a minimum there's no maximum. The unknown unknowns are the things that get you. Seems like it will take X but the frobnicator was broken in ways we couldn't have anticipated so we had to get a different thing and then hack it to make it do what we actually needed etc etc. Each individual item has a low probability of that happening to some extent. When you have a bunch of things in sequence one of them probably will if not more. IIRC each item is described by a poisson distribution. (Have I got that right, mean, long tail). Nobody models estimates as a sequence of dependent, poisson distributed events, that I've heard of at least. If you did you might at least get a range on the estimate. Between 2 and 20 days. That would be more accurate. Useful to anyone much? Unclear.
  • virgilp 5y ago
    I tried to do that! Didn't use Poisson, used normal distribution, but I think that's not so relevant - at the end of the day it's still just more elaborate guesswork. I think what's useful is thinking about the problem, and communicating in group/ disseminating the information (this is required in order to do the typical "planning poker" or whatever planning technique the team happens to use). Whether you end up with L/ S /M or 7/13/21 points or whatever else you use - it's irrelevant, so no need to sweat it; what is relevant is that you discussed the tasks and everyone has some understanding, and maybe they're a little bit better spec-ed now.
    • samus 5y ago
      Normal distribution is deeply inapproprite for time estimation because it yields the same probability for 3x the estimated time than for the negative amount(!) of the estimated time. Your second point rings closer to what we should be doing instead. We should put more effort into analysis and refinement. In my experience, estimation meetings where all tasks got estimated were almost useless in the end; and the most valuable meetings where when we didn't finish to estimate, but instead gained a deeper understanding of the requirements and of the domain.
• movedx 5y ago
  Estimates are just something (bad) management can use to point the finger and assign blame. As long as the middle ground between rough-as-toast and perfection is found when developing something, and that something is delivered, then it takes as long as it takes and that's that.
• sirwhinesalot 5y ago
  The article was doing pretty well until they brought up historical data. The exact same software project done twice can take wildly different times because the team and/or the requirements are different. That's the whole point of Agile, you need regular interaction with a customer to slowly build the software to a state they are happy with. And they should keep paying for the work until it is done or accept whatever state was delivered by the time the budget ran out. If that is not how you are doing Agile you have missed the point. It is not possible to predict software development because unlike a bridge the requirements are never fixed and there are too many unknowns. If you get your requirements fixed at the start, they never change, and you are not going to suddenly have to deal with some library/framework change in the middle of everything, then you can estimate, but you are not doing the software development 99% of the world is.
  • sirwhinesalot 5y ago
    Just to clarify what I mean by "same project, different requirements": you deliver a dashboard to customer A, who is quite helpful and clearly communicated what he wanted. It took 6 months. Customer B asks for a dashboard like that of customer A. However, unlike customer A he keeps nitpicking the design to the pixel, and forgets to mention the company is in the process of migrating database providers. Meanwhile the senior dev who put out all the fires that allowed the first dashboard to be done on time quit due to burnout. The team has no idea why the Jenkins machine keeps crashing. Good luck with your estimate.
• drawkbox 5y ago
  Estimates for tasks/apps/games/projects that have been done before, or known from previous work are usually pretty close. Like for instance making another version of a puzzle game with changed assets and maybe a few new features. Estimates for tasks/apps/games/projects that have NOT been done before, or known from previous work are usually wildly incorrect. Like for instance making the first version of a puzzle game with new everything. Even more so for a new game type that you haven't done before. Software estimation is like 65% correct (2/3rd) usually. There are so many internal, external and just unknown areas that usually these are underestimated greatly. The estimation is off by more when there are third parties or components/frameworks that get you 90% of the way but make the last 10% more tasking than custom sometimes. The nature of software design and development is usually creating new value, in that case lots of those projects are unknown or the first time through something, estimation is almost useless in those areas. It is better to do prototypes to help refine and break it up into parts that can better be estimated. Anyone doing an estimate on a new area that hasn't had a prototype will always be wrong. Estimates more than a month out are also wildly wrong. When you are asked to estimate something big, always just do an estimate for a prototype first before you ever begin to try to estimate the rest.
• TrackerFF 5y ago
  To me, detailed estimates can make sense if you're working in a factory/conveyor-belt environment - where the products are very similar, and you (the company) has shipped hundreds to thousands of such products. At least then you should have some data to look at - but when it comes to boutique products, with new clients, new teams, etc. who knows - you could easily get stuck on something for weeks to months, with no obvious resolution.
• hkt 5y ago
  I recently left a company that had settled on using monte carlo estimation - ignore the ticket sizes and monitor the spread of ticket estimates in order to provide a % estimate to management about when something could be expected. It was pretty crushing to have to constantly explain that my tickets were bigger than the average to a guy who obviously only cared about getting his KPIs down. I left.
• nobody9999 5y ago
  If you're consulting, you absolutely need to have estimates -- because that constitutes the bulk of the Statement of Work (SOW), that is, the contract. And if that estimate isn't within 10-15% (the usual error bars) of the actual project duration/billable hours, there's going to be a problem. What's more, while the developer(s) involved should have some input into that SOW, they shouldn't be writing that document. Rather, they should be writing code for other projects already estimated and sold. As for in-house projects, that's a whole different story and is really dependent upon the processes of that particular organization. All that said, developers should be spending their time developing, and their managers/managing consultants/salespeople should be doing all the other non-development tasks. Edit: Fixed grammatical errors.
  • mrweasel 5y ago
    While I hate doing estimates, mostly because customer can’t tell estimates from promises, you’re right that they are needed for consulting. It’s unreasonable to expect a customer to sign off on some potentially endless number of hours. At the same time, customers also need to understand that tasks which have not been clearly defined, or cannot be clearly defined, can mean that the entire project might result in wasted efford that they will be require to pay for. Estimates exists as an emergency break for run away projects, they should not and cannot be used as deadlines.
    • nobody9999 5y ago
      >While I hate doing estimates, mostly because customer can’t tell estimates from promises, you’re right that they are needed for consulting. It’s unreasonable to expect a customer to sign off on some potentially endless number of hours. At the same time, customers also need to understand that tasks which have not been clearly defined, or cannot be clearly defined, can mean that the entire project might result in wasted efford that they will be require to pay for. Estimates exists as an emergency break for run away projects, they should not and cannot be used as deadlines. You are absolutely right. The caveat there is that a SOW (which includes an estimate) is the meat of the contract between the client and the consultant. Assuming that the SOW clearly defines the scope and functionality, if the consultants can't meet the terms of the contract, they screwed up. Alternatively, if the client changes the requirements or doesn't provide clear guidance as to what exactly it is they want/need, then it's the client's fault. That said, it's the consultants' responsibility to makes sure everything is clearly defined (they are, or are at least supposed to be, the experts). There are certainly circumstances where, even with clearly defined tasks/goals, the project can't be completed within the strictures of the contract. At which point the contract needs to be renegotiated. Which is generally bad for everyone.
• pacifika 5y ago
  Hours typically track money and velocity. These are different things. So book developers per week and use story points for velocity.
• crispyambulance 5y ago
  At the end of the day, it doesn't matter what process is used for coming up with estimates and delivering. Regardless of what you think your process is, somewhere near the top of the leadership pyramid, it all boils down to a customer promise upon which hinges your organization's reputation. In non-dysfunctional organizations people at all levels can understand and adapt to curveballs that cause deadlines to slip. In such places you make estimates to the best of your ability with limited time and resources and communicate constantly with stakeholders on how things are going. The hard thing is it all requires honesty. Probably the most angry I ever got at work was once when, at the end of a project, I was on one of those bullshit status update conference calls with 20 people on the line. Throughout the project the team was I was on was led to believe that we were constantly behind and the deadline was from the beginning impossible to meet yet magically got pushed out several times to give us "grace-time". We cut corners like mad-men, amassed insane levels of tech-debt, and all but put a midget in the machine to make it work. What happened on the call? The product management team congratulated the PM for delivering so far ahead of time. I was so angry I couldn't even talk. Basically, the PM got accolades, the customer got shitty product, and we hated our jobs.
  • lasereyes136 5y ago
    Welcome to corporate America!
  • sirwhinesalot 5y ago
    That is how it goes in the end with any estimate. If it is overestimated the product is delivered with high quality. If it is underestimated the product is delivered with low quality. You can always buy time with technical debt. Our industry always does.
    • willcipriano 5y ago
      I'm in a org that took up a great deal of technical debt, I no longer refer to it as such. It seems to create a false sense of security. Instead I simply call the software what it is, incomplete or unfinished. "We took on some technical debt in Q1." Vs "We didn't finish the project in Q1, but we kinda have something in place that sort of works, as long as you don't look at it funny."
• rdsubhas 5y ago
  The article jumps from detailed hour-driven estimates, to just duking it out. Why does everything have to be so black or white? Why does it have to jump from hour-level to prophecy? Here is what works at a project level: * When estimating, never go any step beyond the Feature level (don't split tasks, most of the time not even stories – just Epics or milestones are enough) * Do RELATIVE COMPLEXITY estimate. Not time. If <epic1> is a medium, then relative to it, is <epic2> large or small? Stop at that level. Don't split it down any further. Now compare just one of the epics to past history. That's all you need to estimate the rest of the scope, as it's all relative. It takes not more than a few hours for due diligence.
  • HelloNurse 5y ago
    This jargon suggests that the scope and complexity of your "epics", "milestones" and "features" are abnormally unsurprising and consistent. Is it because whoever defines them is very good at detailed estimates, or because the work is repetitive and predictable, or because the deadlines are weak and elastic?
  • rgun 5y ago
    I have heard these terms (stories, epics, milestones) a lot. Is there any standard definition for these terms or do they differ from project to project? Any good literature on how to think about them?
• brightball 5y ago
  Agreed completely. My detailed write up here fwiw. https://www.brightball.com/articles/reality-driven-development-fixing-project-management-in-software https://www.brightball.com/articles/reality-driven-developme...
• ubermonkey 5y ago
  Going too deep on any estimate is actually a bit of a pitfall. We see this in my world (large scale project management) where some folks want to plan activities down to the tiniest tiniest level, and it just doesn't pay off. In software, it's hard to do estimates at all if you're a blue-sky environment. Once you have a codebase you're working on, it can be possible to give a better estimate of what it will take to implement a new feature, but the more elaborate the feature, the softer the estimate. We have just shipped a very big change to our product, and we thought it would be a 3-6 month effort to do so. It took 3 years, because it was VERY invasive and VERY complex, and we just didn't understand the underlying challenges enough when we set out to do it.
• marcodiego 5y ago
  Tasking developers with anything other than developing, thinking or talking about thinking and developing is most certainly a waste of time.
• Noe2097 5y ago
  Discussing about the effort required for each task/story, is crucial to generate alignment within a team, determine better the scope of a task/story -- and decompose it, if it appears that the effort would be so big that tracking what has been done and what remains to be done would be intractable. The by-product of these discussion may be summed up as a number. But oh yes its unit must not be time.
• danielvaughn 5y ago
  I've tried to get into the following routine for my team: 1. A daily standup bot pings us with the tickets assigned to us. We respond with a gut-level "percent complete" number for each ticket. 2. The bot tracks these estimates and over time, each team member can see whether they tend to over or under estimate. The point is that we don't try to cram accuracy into developers, we just let them guess and let them see over time how good they are at gut-level estimation. The hope is that they'll eventually improve their estimations, but we're not going to tie it to performance or anything.
• iamthepieman 5y ago
  I work with utility companies on multi year migration projects to move their entire tech stack. This includes, a different database, different data schema across thousands of tables, new front end components, desktop and mobile applications, multiple third party integrations and the training and documentation for the whole thing. The utilities are heavily regulated, often beholden to taxpayers, lawmakers and public utility boards and working on use it or lose it budgets with hard cutoff times for delivery and go-live dates. It's not just budgets and time constraints that make it impossible to do flexible estimates. Their internal personnel all have their regular work duties to attend to while supporting the migration and they can't drop everything for years at a time to dedicate support for the project. Add in the coordination with multiple vendors and you need to be hitting your time estimates, planned years in advance, within a week. Sometimes budgets don't matter that much, once they are a year into a three year project, they will find the money if it's needed, but the coordination alone requires this kind of accuracy. It's amazing what necessity does to your estimates. We have become really good at it. This includes things like "Oh we're working with Oracle, add 3 weeks to that integration just because" or "this is a mobile app for the service techs who tend to be resistant to change, add another week for training and a month for revisions". Yes this is just "padding" but it's very specific padding that's tailored to the type of work being done and has so far been accurate and continually getting better for us. edit: I should add that our estimation process involves multiple week long workshops with all parties. We go over every tool, process, integration and technology currently in use and then write a detailed design document that goes through 2 rounds of review with the customer before being signed off on. These design documents become the basis for a secondary contract to do the actual work and the customer understands that if it's not in the document, it's not getting built or migrated. Any additions require a contract change order.
• r3trohack3r 5y ago
  Only tangentially related but, for project proposals and planning, my favorite exercise is the Heilmeier Catechism: https://www.darpa.mil/work-with-us/heilmeier-catechism https://www.darpa.mil/work-with-us/heilmeier-catechism
• karmakaze 5y ago
  It depends on the developers process of coming up with the estimates. If they're breaking down the tasks, thinking of all the things that can go wrong and factoring in contingencies, sequencing them understanding dependencies, and work other than delivering code, data migrations, support, monitoring, and so on, the estimate could be thrown out without anyone ever looking at it but the developers would have a much better understanding of the project and a good sketch of a plan of attack to make the time making the estimate all worthwhile.
• ricardobayes 5y ago
  What's the best way to start changing company culture like this?
• jrochkind1 5y ago
  Yeah, but how much time will it waste?
• tbwriting 5y ago
  Decomposing projects before you even start coding is everything. The bigger the project, the more likely it is that some small thing - something in the original spec, maybe, or more likely, an unforeseen interaction of its pieces - will be missed and will take an inordinate amount of time to deal with. All it takes is one of these to thwart the entire estimate.
• brainwipe 5y ago
  An estimate is guess but is never treated that way. Budgets are built on it, deliveries agreed. Doesn't matter how much you decompose the task - unless you've coded that exact same thing many times before in the same way under the same conditions then it's just a guess. Been estimating for industry for about 20 years (although not the last 6 because we're agile in the truest sense) and most of the estimates have been wrong - sometimes over, sometimes under. Tech estimates are a lie that loads buy into.
  • commandlinefan 5y ago
    > An estimate is guess It took me a long time to internalize that. See, there's an implied threat - "esitmate correctly or we'll replace you with somebody who will." And believe me, given the mentality of your average project manager, it would be "we'll have you executed first" if executing people who didn't do what you told them to do weren't against the law. What I finally realized was that the implicit threat was a hollow one - there's nobody out there who can do it either, and they know that, as much as they ball up their fists and gnash their teeth when you deliver "late".
    • brainwipe 5y ago
      You're right that there is an implied threat. I've seen work go offshore because there was a dev team to the east that said yes. They said yes to everything. They said yes even though they didn't understand the problem. Yes yes yes. A year later the project was dropped because all that yes was just another lie. Lots of managerial egg on faces and the customers went elsewhere. That kind of management just wants a lie so that they can apportion blame. They're not actually interested in getting a good bit of kit out the door.
• jrs235 5y ago
  https://medium.com/@zack_98398/is-reading-articles-about-whether-making-detailed-estimates-a-waste-of-time-a-waste-of-time-6c9a5439a7ea https://medium.com/@zack_98398/is-reading-articles-about-whe...
• dqpb 5y ago
  I don’t think creating detailed estimates is a waste of time. Planning brings clarity to engineering. However, PMs weaponize estimates against the engineers and that ruins the whole exercise. Also, teams should use a betting market with real money. People deserve to be paid extra for being right.
• rackjack 5y ago
  "What a useful thing a pocket-map is!" I remarked. "That's another thing we've learned from your Nation," said Mein Herr, "map-making. But we've carried it much further than you. What do you consider the largest map that would be really useful?" "About six inches to the mile." "Only six inches!" exclaimed Mein Herr. "We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all ! We actually made a map of the country, on the scale of a mile to the mile!" "Have you used it much?" I enquired. "It has never been spread out, yet," said Mein Herr: "the farmers objected: they said it would cover the whole country, and shut out the sunlight ! So we now use the country itself, as its own map, and I assure you it does nearly as well." from Lewis Carroll, Sylvie and Bruno Concluded, Chapter XI, London, 1895 from Wikipedia: https://en.wikipedia.org/wiki/On_Exactitude_in_Science#Influences_and_legacy https://en.wikipedia.org/wiki/On_Exactitude_in_Science#Influ...
• denton-scratch 5y ago
  > an agreed upon estimate That's not an estimate; that sounds like the outcome of a negotiation. If someone demands an estimate from me, they get one - if it's not the one the manager wanted, he's free to substitute his own. I'm accustomed to managers upping my estimates by 10%, and I've known them to increase them by 100%. For small jobs, requiring an estimate instantly doubles the estimate, because it takes longer to produce a good estimate than it does to do the work. If you reduce my estimate, or try to talk me down, the new estimate is your estimate, not mine. And if you think it's fair to try to nail me to my estimate, then you obviously don't know what "estimate" means, and I need a new employer.
  • commandlinefan 5y ago
    > If someone demands an estimate from me, they get one See, you're missing the point of the estimate game. It's not to figure out how long it's going to take - they already know nobody knows the answer to that (and they've already decided how long it's going to take anyway). The point of the estimate is to bully you into making a completely unrealistic promise and then use that promise to bully you into working nights and weekends to keep it (one of the reasons they love work visas that are tied to a specific employer). It usually works on young naive developers for a while, until they either ulcerate themselves into an early grave or develop a healthy cynicism about estimates. Actually trying to deliver quality software is, incidentally, never one of the goals, just getting promoted by abusing people below them.
• dasil003 5y ago
  After a couple decades working at companies and projects of all sizes, I always cringe when I hear prescriptive ideas about some abstract approach working or not working. In my experience, lots of different things can work, but there are more ways to fail than to succeed. When we're talking about large scale software projects with fluid requirements ultimately success hinges primarily on having competent individuals and trust between them. Without trust everyone is trying to cover their own ass, and in the case of large projects most of them will easily succeed since you only need one scapegoat. This is the type of environment where detailed estimates are demanded so that management had a paper trail, or where engineers implement the letter of a PRD and never propose changes to inconsistent or awkward requirements because it's too much energy and they'll be gone before they have to deal with the tech debt anyway. Often times in these type of environments someone will propose a process such as scrum to address particular pain points, but layering a process on a dysfunctional team doesn't address the core issue; at best the routine can shield individuals from chaos, but it won't actually improve throughput in any meaningful way. At the end of the day, the best you can do with large scale estimation is get a handful of your best engineers who can roughly envision what needs to happen and have them chalk out a rough plan at a very coarse granularity and with key assumptions enumerated. Then with your best product people chalk out a strategic roadmap showing where they believe the product should go over the next 5 years so they can take that as input into account for architectural strategy. The key thing is that everyone understands that all long-term plans are subject to unknowns and change for all sorts of reasons—the point is not to pin people down but to leverage individual expertise to develop a best guess at what is possible. This is where trust is at its most tenuous and stands on a razor's edge; all it takes is one bozo to treat these things as guarantees and start throwing people under the bus when things go wrong, and before you know it trust is gone and everyone is in cover-your-ass mode. Now the group has lost the ability to accomplish the most ambitious goal of which they would otherwise be capable.
• commandlinefan 5y ago
  When I was working at a big online travel site, we used to have a requirements document template which started with a "flexibility matrix". It was a two-by-two grid with "scope" and "date" along the y-axis and "most flexible" and "least flexible" along the x-axis. The stakeholders were supposed to indicate to us whether the scope or the date was "flexible". Of course, we got an unending series of requirements where the date was "least flexible" and the scope was "most flexible", never ever ever the other way around. It got to the point of such ridiculousness that we finally started trying to flex the scope because the dates were so unrealistic. Management's response? Add another row and column in the matrix of "resources" (that is, it's ok to add people if you need to) and "somewhat flexible". So after that all of our requirements were "date least flexible", "scope somewhat flexible" and "resources most flexible".
• jb3689 5y ago
  I learned very early on in my career that the right way to do estimates is to do multiple estimates and cross-check them. If you have multiple estimates using different methodologies and they all are fairly close then you know you have a good estimate. Time estimates are still useful even if the range is large. If a high-bound estimate is still acceptable - great, ship it. If a low-bound estimate is barely good enough, that is a huge risk. If you get multiple estimates from multiple developers and they are wildly different, there's a conversation (i.e planning poker)
• xputer 5y ago
  I think this article misses the point. Estimation should never be a goal. It should merely a tool that helps with identifying risks early on and that helps with identifying the "minimum viable product (MVP)". The term MVP was never mentioned in this article and I don't see how you can have a serious discussion about project estimation and dismiss the benefits of agile without even mentioning the term MVP...
• Zigurd 5y ago
  Estimates are mostly wrong. Retrospectives always have hard data. Many projects seem not to have the time for retrospectives. There are few other places in project management overheads to look to find the time for retrospectives. Cut the time for estimation, and reduce the focus on them. If you use retrospectives well, you may find you do not need to spend that much time on estimates, and even further reduce the use of estimates.
• AnimalMuppet 5y ago
  Among other things, Extreme Programming says that estimates increasingly diverge from reality if they're longer than three weeks. So: Do you need accurate estimates? Then you need detail. The fuzzier the estimates can be, the less detail you need. Do you need developers to do the detailed estimates? Yes, for two reasons. Politically/socially/culturally, having someone else telling you how long something is going to take you to do is... not received well, given normal human nature. Functionally, the developers have to be the ones to do the detailed estimates, because they're the ones who actually know what the details are. All that said... overly detailed estimates are a waste of time. Don't break it down into a series of tasks, each of which take one hour or one day.
• todd8 5y ago
  A co-worker of mine had a good idea: require management to seal within an envelope the cutoff value that would determine the outcome the decision that required the estimate (e.g. Estimate > X then Do A and Estimate < X then Do B). When the estimate comes back open the envelope. So often, management wants a certain outcome, but needs the estimates as cover for making the decision. Just demand a detailed estimate, fool around with the estimates details--no matter what the estimate ends up being, and finally say "Estimates indicate that we should do this.", which is what they wanted to say all along.
• Dumblydorr 5y ago
  Simple question: Why are deadlines needed?
• MeinBlutIstBlau 5y ago
  I like deadlines. I like when I'm held to them. I like it that there is pressure to work faster. What I don't like is someone who doesn't know how to code can make empty promises and then I'm the one who has to be held responsible for their unrealistic deadline. When there are bugs, I'm also the one who gets blamed. Fortunately I haven't had to deal with this much in my career, but the few times I have, it is really tiresome that you have to wait until there is a crisis before you find out if your supervisor truly has your backs or not.
• pxc 5y ago
  > I said a 8 but I don’t really know why > Could be a 1 or it could take my whole life those lines made me laugh out loud the first time I heard them https://www.youtube.com/watch?v=sh7A8UChBTI https://www.youtube.com/watch?v=sh7A8UChBTI
• black_13 5y ago
  Not only is it a waste if time but its spawned an industrial complex of time wasters known as product owners scrum masters and the company atlassian
• balaji1 5y ago
  Civil engineers come up with estimates for time and cost to complete projects or upgrades. These estimates are contractually agreed with provisions for delays and overruns. Developers are not doing engineering work?
• turbinerneiter 5y ago
  I think it's fun to read all the stuff about how it is impossible to estimate what software costs. What is so magically different about it? All other professions can do it. And not just the other professions, our company is one of many software shops that sells projects. We need to be able to make good estimations to be profitable, and we are. Maybe it's all the VC and BigCorp money that is stopping you.
  • izacus 5y ago
    > What is so magically different about it? All other professions can do it. And not just the other professions, our company is one of many software shops that sells projects. We need to be able to make good estimations to be profitable, and we are. And all other professions regularly overrun costs and dates of delivery just like software. Let's stop acting like other engineers actually hit their deadlines regularly - just last year was there a news about a miraculous Swiss tunnel project which, as a very notable exception, actually hit its target deadline.
• Kalanos 5y ago
  earlier in my career, I would have said that, yes, it is a waste of time. on one hand, estimating essentially requires architecting, and that's never a waste of time. on the other hand, you could argue that even w a good plan you won't know where the 1-2 rabbit holes will be (some subtly critical facet of my use case not jiving with the proposed toolset). So i'd say get a decent plan (weeks, not hours) in place and give yourself a 50%+ buffer.
• Cyberthal 5y ago
  Better to deliver incremental evolutionary value, so that the business side gets useful feedback iterations on what engineering can deliver. This allows the company as a whole to iterate its customer relationship.