31 ms·

Why are developers expected to estimate tasks at all?

• Blackstrat 4y ago
  I managed developers for a long time, prior to retiring. Generally, except when I worked for a company filled with PMPs, I asked developers when they would complete an assignment if things went well and if they didn't when. I didn't ask for task level estimates. I did ask for descriptive write up of the direction/approach and any intermediate milestones that told them they were on track and how well the project was going. Over time, I learned who was good at this type of estimate and who wasn't, who sandbagged, who was overly aggressive, etc. It took some time to get my bosses happy with the lack of detail, especially since I usually gave the pessimistic estimate or something close. I hated being micro-managed when I was writing code everyday and wasn't going to follow at practice that I myself had hated. This process worked great until I worked for a PMP-driven company, where projects routinely crashed and burned. Slack by Tom DeMarco should be required reading for all PMPs and their managers.
• 0x69420 4y ago
  the top voted answer lectures OP about ackshually having an X/Y problem, coupled with with a cheeky boomer pull-yourself-up-by-your-bootstraps “you're part of the problem; be part of the solution” to downplay any responsibility on the part of management this is such hilariously distilled peak stackoverflow that it belongs in the hall of fame
  • thih9 4y ago
    This didn’t read cheeky to me; how I understood it is: it’s pointless to convince the management to prioritize dev needs in this scenario, either throw the management some bone or find a better workplace.
  • rendall 4y ago
    I agree that the top-voted answer is obnoxious, and right off the bat: "Most of your question is really a rant about how things work at your workplace. Discussions about toxic workplace practices per se are out of scope for PMSE." Not a friendly, charitable answer, and it is right at the top. As to the question itself, crowd-source the estimation, is the best approach, in my experience. Get the team together, each member write down an estimate, and reveal all the estimates at once. If there are outliers, have a discussion, otherwise round up and move on to the next estimation. If you're in a scrum shop, you can abstract the estimation by one level and call them "stories" and you're estimating "complication" not "time", which is even better.
  • sergiotapia 4y ago
    I agree with you on this being peak stackoverflow. It's a shame how these people install themselves as mods and just run amok. What a shame. The first year or two of stackoverflow was the best times. You could actually have great conversations with professionals.
  • siva7 4y ago
    There is some reason why so many people upvoted this comment and not yours to the top. Many readers here are highly experienced developers and know that there is always some responsibility on the part of management but this question also strongly tells a lacking responsibility on the developer side.
• benjaminwootton 4y ago
  It’s a very naive question even if I try to be charitable. I assume most developers would be more business aware? A few obvious reasons: - The buyer has to make commitments externally, for instance to customers, partners, finance, marketing, his boss; - The buyer has dependencies on those external resources and needs to plan for them; - The buyer has a limited pool of resources and needs to know when they are free for the next task or project; - The buyer needs to get an idea of costs to complete the feature and secure the budget; - The buyer needs to make priority calls. If feature X is significantly more effort than feature Y then we can prioritise accordingly; - The buyer is paying and simply wants to know when he will get his shit. I wonder if the person asking the question would be happy to let someone do a job in his home with an uncapped budget and timeline?
  • pmarreck 4y ago
    agreed with this. it's almost like this person has never had to pay for labor before
    • commandlinefan 4y ago
      You’re all acting like he does know, he’s just not telling you. Step back for a moment and consider how things change if he actually doesn’t know and not even a water boarding session will get him to tell you how long it’s going to take. Now what? You either live with the uncertainty or fire him and replace him with somebody who can conjure up estimates - which, presumably was what you were trying to do when you hired him in the first place.
      • highwaylights 4y ago
        I mean I would definitely give you the estimate before it got to waterboarding. The quality of the estimate would be unaffected.
  • a_t48 4y ago
    Yeah I’d hate to be working with this guy. Your coworkers care about when things get done, too. Nothing more frustrating than to sit on your hands because of a dependency on some other team.
• mutatio 4y ago
  My take is the comoditisation of developers, pushing as much responsibility to them in search of efficiency. Arguably they are best placed to know how long the implementation of X might take, but often the lines are blurred, i.e. developers also become business analysts to spec out the work to determine what the business really needs. Personally I find it exhausting and is one of the aspects that makes me dream of doing something else. Maybe GPT-4 will put me out of my misery soon.
• xupybd 4y ago
  I get the feeling they're asking why can't management estimate for me based on current velocity.
• Peregrine1 4y ago
  “…completely unmoored from the purpose of business, which is to make money by providing a product or service within a given schedule, scope, and cost.” Or perhaps to solve an important problem in the world, within a given scope and cost!
• kodah 4y ago
  It is true that scope management through batch theory delivers consistent results, yet the quality is almost always below what would continue a products profitability, almost always initially falls below user expectations, and almost always includes a tradeoff for engineer sanity in the form of maintainability. What the PM is not saying, or the quiet part, is that from their perspective "it is your job, do your job." Frankly, that's a piss poor take as well. People are griping about the relationship between engineers and businesses because it's taking a toll. Telling people to shut up and get back to work, worse, alluding their gripes are narcissistic at best is a woefully attrocious take. Businesses can be better, but part of being better will be taking bets on how to make things better that the engineers (workers) don't solely shoulder or take blame for. Hell, it'd be nice to see the business aspire for internal change where the engineers aren't asked to change at all.
• whiplash451 4y ago
  The one reason I have seen it useful for developers to estimate tasks is that it helps spot misunderstandings early on. As in: wait, your estimate is 3 days and mine is seven, are we talking about the same thing?
  • sigstoat 4y ago
    yes and then we foolishly just take the average or something instead of saying “oops clearly this needs to be broken down further”
• rileymat2 4y ago
  > Get pressured to be more accurate and to bring the estimate down Of course people want it quicker, but this is the problem, stick to the estimate and the problem goes away for the most part. Negotiate on scope if it is too long. Communicate as early as possible if there is a mistake in the estimate. At that point the problem largely goes away. Edit: When communicating about the mistaken estimation, include which assumptions or surprises came up.
  • commandlinefan 4y ago
    > stick to the estimate If you were right. I’ve never met anybody who could accurately estimate a software project, and I’ve been doing this for 30 years.
    • rileymat2 4y ago
      It is a rare combination to have the technical skill and experience along with soft skills like humility that make it somewhat rare. But useful estimates are absolutely possible. The question is one of range, with humility you can hit estimation ranges defined by how familiar the project is and how well defined the project is. There are many developed techniques that we just don’t implement. By in large, most estimates I have seen were some weird gut. Not defined no milestones. “Yeah, about two weeks boss” Often estimates come before requirements. Those will be wrong more often than not. Many times I will estimate the estimate. The “bigger” the project the longer the estimate takes. People are afraid to admit any knowledge gap. People switch jobs every 2 years, I have been at the same place 10, and before that 8. You learn the cadence, you learn the pain points. You learn the traps. You learn the domain. These can be accurate. But this is not the OP’s issue as stated, he is lowering estimates in the face of pressure. This will nearly always fail.
    • newswasboring 4y ago
      Yeah, all models are wrong, but some models are useful. As far as I understand, the goal of estimates is not to pressure you, it's to promise something to someone. As long as you are good enough, business decisions can be made. And that includes figuring out when something is off track, which is one of the primary goals of management.
• lr4444lr 4y ago
  I think a lot of people commenting are not giving a charitable interpretation to the question. Now why any estimate is needed, but why should the dev be expected to have the right prognostication? As a dev, I have to admit it's a fantastic question. The reason estimates go awry almost always come down to things outside my control. Why am I expected to make predictions based on that? The people getting paid salaries to have a bird's eye view and veto power over those kinds of changes that could screw with my deliverable should be the ones knowledgeable and accountable for that estimate. And if I agree to it and fail to meet it, the judgment should go above both of our heads: was I delinquent, or was I blocked because someone else didn't do due diligence?
  • notimetorelax 4y ago
    If you abdicate any responsibility to estimate the work how can you agree to any estimate?
    • lr4444lr 4y ago
      I am responsible for telling the person promising how long the work would take as scoped out, given the competing or potential problems which that person is also responsible of informing me exist. It's not that I provide no info - it's that I can't be authoritative about delivery times in an ecosystem I don't entirely control.
      • notimetorelax 4y ago
        I think this argument is not about engineer vs manager. It’s about junior vs senior engineer. As you gain seniority and tech-lead others you take on this responsibility. I agree that junior engineers shouldn’t do estimation, but rather senior engineers should set the expectations.
  • cntainer 4y ago
    The people getting paid salaries to have a bird's eye view and veto power over those kinds of changes that could screw with my deliverable should be the ones knowledgeable and accountable for that estimate But they are accountable to their stakeholders (clients, upper management, etc). They take your estimate and many others from other people in the team and work those into a delivery plan. A good manager will know how to manage risks and remove blockers in a way that gives a developer the best chance to work within the estimate. A bad manager will usually have no plan and put all the blame on the developers if things go awry.
• analog31 4y ago
  Perhaps by coincidence, there were a couple of front page threads last week about the cost and duration of major government infrastructure projects. But actually it's a recurring theme. People speculate about things like government bureaucracy, NIMBYism, and project complexity, but ultimately nobody knows the answer. And some of the easy answers break down if applied to the management of software projects.
• treis 4y ago
  Most of us are carpenters since carpenters don't build literally the exact same thing over and over either. They build similar stuff like decks and houses over and over. But they're all different to some extent. Programming is the same. The exact functionality is the different but they're all accomplished using more or less the same techniques.
• vasco 4y ago
  Get your bathroom remodeled in your home and have the worker tell you it'll be done whenever and you'll understand why developers (or any hands on worker) is lacking in their skill and practice if they have no clue how long it takes them to perform their work. "Management" or a PMs job will then be to aggregate those estimates so they can estimate at a higher level than you, similar to a project management in a construction site. But each person needs some semblance of an idea of when their part will be done. The same way if you were remodeling your bathroom and your garden and want to tell your kids when the construction around the house will be done, you'll need the gardener's estimate and the plumber's estimate, plus maybe some buffer at the end, plus some time to go with the wife to get a new shower curtain, etc.
  • dieselgate 4y ago
    Thanks for taking this avenue, the comparison to carpentry really annoyed me because all bathrooms or cabinets, or e-commerce/CRUD apps are the same right? (just because we're all tired of working on them doesn't mean our work is all copy and paste) The most difficult part of any "hands on" job is time estimation - two people could give estimates of 3 days or 3 weeks on the same project and both be right.
    • srj 4y ago
      I would assume the individual jobs could be fairly different, e.g. the plumbing doesn't come into the necessary places, shutoff valves not working.
    • JumpCrisscross 4y ago
      Also, commissioner artists and authors are also asked for estimates. This is just basic professional courtesy when working with others.
  • ResearchCode 4y ago
    We're doing applied mathematics, not bathroom remodeling. Try telling a mathematician to "story point" the conjectures they're working on.
• yk 4y ago
  The question is certainly naive, but the answers read like satire of the worst project managers I ever had.
• hkpack 4y ago
  The work developers do varies, so this question in general makes little sense. Sometimes, developers literally do R&D without knowing, whether they will be able to solve the task at hand at all. Other times, they use proven solutions for typical problems. I saw the most issues arises, when management starts to confuse between the two. From the business perspective, you definitely have to balance the ratio of the two.
• Mizoguchi 4y ago
  Producing estimates is a necessary evil for multiple business reasons. A fundamental skill of any experience Software Engineer is to be able to make decisions under lots of uncertainty, and that includes allocating resources to a task for which a lot of information is not yet available. Yes it sucks but it needs to be done.
• osigurdson 4y ago
  If you want to see an engineer squirm, ask them to estimate how long something will take. If you want to see a manager / product person squirm, ask them what the net present value of the deliverable is. We should just accept that significant uncertainty exists in both situations. If you can’t handle risk, liquidate company and invest in t-bills.
• sarchertech 4y ago
  I agree that time estimates are a necessary evil, but I disagree that story points are useful for anything really. This comment from the article was interesting and it matched my experience: > The law of large numbers only applies if a) the population is sufficiently large, otherwise outliers will dominate b) the estimates are at least mostly independent, otherwise systematic bias will skew the result and c) the estimate is in fact the expected value (mean average) of the probability distribution of time taken. If the estimate is a mode of the probability distribution, then you can not meaningfully add the estimate directly and be able to meaninfully say anything about the resulting distribution.
• m3kw9 4y ago
  Cuz proj managers need some fall guy when they estimate a project timeline and submitting it to upper
• birdymcbird 4y ago
  every business exist to make money or something of value to its shareholder. You can hire contractor to modernize you kitchen or paint wall.. you need some understanding of exactly what is scope of work, what is $ cost, what is the quality, and any other constraint. the contractor cannot just say i have no idea how long it will take. there has to be some start and end date. why some programmer think they do not have to provide any estimate at all is perplexing. is your paycheck an infinite money stream? does your employer not have commitment to deliver something by specific date? or do you want someone else to go create estimate of how long YOU need to complete some work? this is why tools like scrum come in. estimates not a perfect science..so break down scope of work into small and small chunks until we can say “ok…this piece take 3 days”.
• r2b2 4y ago
  Money now is more valuable than money later. As someone who has both built and sold software, it's simply to be able to sell software before it's complete. Without estimates, you can't sell something that doesn't exist yet. This doesn't change the fact that requiring estimates is a bad idea if you want great software. The best software is built well, then sold.[0] Great software later is more valuable long-term than bad software now. -- [0] The best case is actually to sell software without a timeline. But most organizations are not able to operate this way.
  • tsimionescu 4y ago
    Still, some level of estimates can always be given. I have never embarked upon a programming task, even a very novel one, where I couldn't say whether it will take two hours or two years. Now, whether it would take two weeks or two months has sometimes happened.
• deleted 4y ago
  [deleted]
• cntainer 4y ago
  I expect a plumber to give me an estimate of time and cost for his "tasks" before starting work. Even if he doesn't tell me the exact cost upfront he'll still be able to tell me roughly if he'll be done in 2-3 hours or less/more. If I have a big project and I'm dealing with a plumbing company I might not be talking directly to the plumbers but to their manager. The manager will usually ask for time/complexity estimates from his plumbers before sending me a quote. The manager will usually factor into the quote any risks plus the company's profit margin. There's a lot of talk about agile, scrum, no-estimates and so on, but a big part of the software industry still works with time estimates and budgets communicated up front.
• jjluoma 4y ago
  If only the task that the estimate is for would not change much after the estimate has been given.
  • cratermoon 4y ago
    'Walking on water and developing software from a specification are easy if both are frozen.' – Edward V. Berard
    • commandlinefan 4y ago
      And remember - the people asking for estimates want the estimates right now. I could give you an amazingly accurate estimate of how long a software project will take - it just might take me longer to produce the estimate than it will to produce the software.
• thih9 4y ago
  Perhaps a solution is to distinguish between an estimate and a detailed plan. One is a quick guess with high risk, the other takes time and research to prepare and the risk of running into a delay is lower. And often the best solution is to have none; perhaps part of the problem is that people are often too afraid or have not enough trust to work without plans or estimates when needed.
• mkl95 4y ago
  I have found engineers' estimates to be accurate and straightforward when the team owned all the resources needed to complete their tasks. Whenever it depends on some unreliable factor (often some unavailable expert) estimates are useless. Estimating tasks without estimating each team members capacity is basically lying to yourself.
• amelius 4y ago
  Hmm this could be the perfect task for GPT: estimate projects.
• Veuxdo 4y ago
  "Tasks" are the lowest-common-denominator directives that developers should refuse to estimate as a matter of self respect. If management wants an estimate, insist that they do their job and write a proper story instead.
• sixothree 4y ago
  As a developer, I love being able to give you an accurate estimate. It means I know the weight of all of the tasks and likely have done them all before. So creating an estimate is basically a rough outline of the tasks I need churn out. I can go on autopilot and crank out some solid work that improves on previous well-tested experience.
• buro9 4y ago
  To set expectations (to sales people, PMs, managers, etc), i.e. to allow marketing to be aligned to a feature launch, or contacts to push things backwards to accommodate reality To ensure alignment and a shared understanding of the scope exists, i.e. to prevent doing more than necessary or less than expected To hold people to account, i.e. some people really are low performers and seem to evade being accountable for their performance They shouldn't be deadlines, but it's not unreasonable to expect someone to know how they're going to approach something and what amount of effort and time that may take
  • rendall 4y ago
    > To hold people to account, i.e. some people really are low performers and seem to evade being accountable for their performance Maybe I'm lucky, but in my experience this is quite rare. It is true, however, that if this is the expectation (and you matter, e.g. you're their boss), people will lower their capacity to match.
• dboreham 4y ago
  Because magical thinking and lack of boundaries.
• ChrisMarshallNY 4y ago
  Well, if it's a one-track project, estimates can be treated casually. However, I spent the majority of my career at hardware manufacturers, where software was actually kind of an "annoying extra requirement" (I'd like to think that's changing, these days, but not so sure. Contempt for software seemed to be a fundamental pillar of hardware engineers). Our projects were always done by fairly massive, interdisciplinary teams, and everything had to "sync up," at the correct time. If the hardware would be ready at a certain date, the host drivers needed to be ready then, because the SDK people and the QC team needed them, etc. And even though engineers love to rag on marketing, they have to have very complex projects, to generate buzz, advertise, ship, distribute, etc. Hardware is a lot more difficult to distribute than software. Also, Quality was really important. A recall of hardware is a nightmare. Sometimes, we could be heroes, and save customers from hardware defects (like having an image processing filter to correct some chromatic aberration). Other times, we could brick the unit, or wipe out customer systems (I once wrote a SCSI driver that wrote to sector zero on hard disks -oops). Estimates -not just software estimates- were critical.
• zabzonk 4y ago
  This is a question i have often asked. Just over 20 years ago I was renting a flat in Edinburgh where just opposite a steel-framed office block was being built. The construction really interested me - i saw several guys and a crane operator swinging up a huge horizontal i-bar and bolting it on to the vertical bars, with no obvious problems. Compare that with adding a new interface to something. And do you think these guys were asked how long the bolting would take? No, they were told how long they had to do it, by the engineer in charge of the site, and they did it. This is why all software project managers should be highly competent programmers and should do all task (a bad word, imho) estimation themselves. After all. they are hopefully more experienced!
• daviddever23box 4y ago
  Here's a casual thought: if you, as a developer, were able to generate code instantaneously, what time would be required to 0) gather initial requirements and create Jira tickets, 1) re-work your code based on changing requirements, 2) re-build and re-package your solution for testing, and 3) have your dedicated QA or acceptance team evaluate your packaged code in a staging and or production capacity? Because those components are, fundamentally, a significant portion of the time estimate required to make plans from a business perspective–and nearly all of them are largely outside your control. AND-most importantly-your ability to gauge those timelines, without a single Git commit, is what separates highly-paid engineers from n00bs.
• bdangubic 4y ago
  Why are plumbers/carpenters/roofers… expected to estimate their tasks?! And if you say “oh there is a BIG difference” there really isn’t (other than that overwhelming majority of developers are terrible at their craft, not their fault there is just entirely too many developers)
• ResearchCode 4y ago
  Because of non-technical micromanagers.
• JustSomeNobody 4y ago
  The only time I get irked about giving an estimate is when I don't get time to think about it. I need to be able to think through the request, jot some questions (and jot down what I anticipate the answers to be and how it affects the estimate), make some notes and think about what impact that feature will have. It's not a good look for a manager to ask for an estimate in a meeting and expect a reply immediately. But, it happens.
  • WastingMyTime89 4y ago
    > It's not a good look for a manager to ask for an estimate in a meeting and expect a reply immediately. But, it happens. The only time I ask this question is in meetings where a project is late and we are talking remediation or someone is proposing to do something new. I don’t do it because I expect people to deliver estimate instantaneously. I do it because I expect professionals to come to meeting prepared after having done their job.
    • JustSomeNobody 4y ago
      > I do it because I expect professionals to come to meeting prepared after having done their job. Can't do your job if you're not given time to.
• remkop22 4y ago
  As someone who moved from a practical engineering field into software engineering, this separation in tasks between management and developers seems weird. Engineering in general is about finding a local optimum in a multidimensional problem space, one of the axes could be time, another one could be complexity or agility. For me, an engineer is not just tasked with outputting code, but also working out these optimums.
  • rendall 4y ago
    Can you expand more? This seems like an important insight to me.
    • remkop22 4y ago
      Firstly I think the most important thing in engineering is nothing is free. If you change a parameter in your design something else has got to give. If you increase the cargo capacity of a plane it is probably going to have a slower cruising speed. The hard part is finding the sweet spot that exactly fits the requirements of the client or use case. And also! now a dosen of other parameters have shifted to, like weight balance or climbing rate. How do these fit in? Now for software, let's say you have two clients with almost identical requirements for a piece of Software. The only difference being one of them thinks time to market is important, the other one has less focus on time. As a software engineer you should produce two very different pieces of Software for these clients. You will have to make decisions based on the time it will take to implement something and also understand the effects of this on other aspects of the end product.
• cheezebubba 4y ago
  I haven't seen anyone talk about the elephant in the room - only part of the reason for giving estimates is practical. Most of it is political/psychological: https://news.ycombinator.com/item?id=23093789 https://news.ycombinator.com/item?id=23093789 The political solution is to give an estimate assuming nothing goes wrong, and then when things go wrong blame those things. This lets everybody from you up the chain look good while not changing anything.
• gabereiser 4y ago
  If this person worked on my team, they wouldn’t any longer. Not even addressing the question at hand of why we give estimates, the idea that you just want to code without any repercussions shows me that you don’t understand the job. Companies (most) don’t hire you to perfect the art of software. They hire you to deliver business value. Estimates are them trying to frame how long it takes to get that value. Coordinating the delivery of that against other company projects/plans or customer project/plans is the business you are in. If you want to just code and experiment, go pursue a PhD and stay in academia. The people who work for me, with me, report to me, or interact with me know that I’m always focused on value. I could program the best platform I could design but without customers that see value in it, it’s worthless (or worse, costs you money).
  • ShamelessC 4y ago
    If I worked on your team, I wouldn’t any longer.
    • newswasboring 4y ago
      Would you like to elaborate on why?
    • gabereiser 4y ago
      That’s fair. At-will employment laws…
  • rendall 4y ago
    > If this person worked on my team, they wouldn’t any longer. So, literally, if you found that a member of your team was the one who posted this question, you would work to get them out of your team? Fired, managed out? No discussion? No, for instance, conversation about how things could improve?
    • gabereiser 4y ago
      No, not in the slightest. I’m not one to hunt people down. I would tell the author that here’s what we do, why we hired them, if that isn’t in alignment then we wish you the best and will gladly offer a referral towards your next endeavor. Jesus. I’m not toxic. I’m also not going to let toxicity ruin my team(s). Such as baulking at requests for timelines. If you don’t know, say you don’t know to your manager and let the manager, manage. The author doesn’t understand their place in the business just like you don’t understand that you can have hard conversations without playing office politics or being a toxic manager. Hunting people out that don’t believe in the mission. I never work to get people fired. They usually do that on their own.
• DeathArrow 4y ago
  I am amazed how my team mates are trying to always severely underestimate tasks. To the point that our manager has to intervene and raise the estimation a bit. Why are SWE and programmers so afraid of bussineses persons, product owners, scrum masters and higher management? Whenever I thought my estimation is good, I fought for it with the teeth. It could be the CEO wanting it done by tomorrow, if I said it would take a week, it took a week. And if an user story is not well refined, is subject to change while it is in implementation phase, is unclear or have some uncertainty, then it's absolutely normal to add time for that. And I hate estimating in points instead of days. The bussines is always pressuring towards doing more with less people, and as a result velocity rises, we are expected to do more points and people stay after hours to do the work.
  • Tade0 4y ago
    > Why are SWE and programmers so afraid of bussineses persons, product owners, scrum masters and higher management? I've seen this many times and I used to be such a person. It stems from expecting to be at peak mental shape all day (because that's what you've shown in your job interview) - ultimately overestimating one's capabilities. I had to wait to my thirties to understand that nope, I can't sustain this and I should acknowledge that I'm not really putting in 8h of focused work daily. I see this as a rite of passage for a senior developer - you can't be dependable if you're not true to yourself.
    • DeathArrow 4y ago
      That makes sense indeed. It's more of juniors or middle programmers who usually underestimate. And the poor folks end up working nights and weekends to try to meet that estimation. But it's not that they will have more respect, recognition or salary raise if they work more than they would sign for. If I were a tech or people manager I wouldn't expect my team to overwork, just do a decent job in a decent amount of time, i.e. no slacking. And our current people manager which used to be a programmer does that. When he feels a task is underestimated he asks to raise the estimation. And the PO and the scrum master comply even if they don't like it.
• femto113 4y ago
  Managers don't actually want estimates. A genuine "estimate" would be a probability distribution over a range of dates, with some point identified as the most likely delivery date and a roughly even chance of being early or late relative to that point. What they actually want is "the earliest date you cannot currently prove to be infeasible", which essentially is the near end of that date range, so there's a roughly 100% chance you'll come in after it. I've had exactly one manager who (after I explained this) admitted that was actually what he wanted, but I couldn't convince him of the utility of asking for genuine estimates.
  • austinjp 4y ago
    Bingo. And not only is it a probability distribution, it's a constantly changing one.
  • jiggawatts 4y ago
    Reminds me of bureaucracies deciding that staff should have the “Worst possible equipment they cannot prove actually stops them working.”
  • re-thc 4y ago
    You cannot prove anything either way so that's also a moot point. If someone can prove you wrong on it they should do the estimate and if they can't then anything works. We're all in the world of microservices in large orgs that don't talk to each other. Who knows what will be impacted...
• joe_the_user 4y ago
  The best manager I ever had used this process: - Manager asks for programmer for time estimate - Manager writes time estimate - Manager gives time estimate to client. It might seem easy but it had the consequence that the developer thought carefully the first time. There was zero pressure and things worked fine.
• pjmlp 4y ago
  Because Software Engineering is much more than blindly typing code. Yes, business and domain knowledge is part of the job. The only developers I don't expect estimations from, are juniors and trainees.
• tclover 4y ago
  Time roughly estimated to complete 1 task - 2 hours. Time it took - 22h. Sometimes I just hate my life
• nitwit005 4y ago
  > It would then be the manager's responsibility to extrapolate my likely completion date, learn my accuracy over time, adjust to it and manage expectations of upper management. That is something that should be happening for job evaluation anyways. I've also never seen it happen. Seems to be an unfortunate trend in management in general. My mother worked as a nurse and complained the managers didn't bother to walk the halls to check up on things.
• newswasboring 4y ago
  In all these discussions, what I pick up the most on is the adversarial type of relationship people have with their managers. I don't get it. Everyone is pursuing the same goal; aren't we partners in this? I have only ever worked in big companies (20k+ employees), and its rampant there. Perhaps I have been incredibly lucky, but I have thrived in my career by actually forging a partnership with my managers and leaders. Work acquaintance does not have to be a cold, cutthroat relationship. There is usually enough to go around, and you win more as a team.
• bazmattaz 4y ago
  As a product manager I often ask for and estimate for a piece of work but it’s not so I can hold the engineer to their estimate. It’s often so I can understand capacity in the team and plan accordingly. I often just need to know; is this a week or two of work or a few days. Sometimes I might need an estimate if another team is dependent on the work being completed but i understand that most estimates are very rough and that I might likely need to go back to external teams and manage their expectations. I think the problem that OP highlights is not necessarily a problem with estimations it’s a problem with management holding engineers to account. This sounds like a company with poor culture. The solution to this is not to give estimates any more, the solution is to fix a toxic culture of management requiring accurate estimates and then holding engineers to account
• csours 4y ago
  How much will the team have to learn as individuals and as a team? How many components can you enumerate and in what detail? How many tries will each component take? How many interconnects to "external" systems are there? Risk is time, how much risk is there? What are the non-functional requirements? These will be dropped when time is short. How motivated will your team be? What will make them depressed about this project? What will de-motivate them? ===== Don't ask a developer for estimates in terms of time. It's not useful to them, and it's not informative to management.
• pizlonator 4y ago
  Manager here. I ask everyone for estimates. Then I track how long shit actually takes. I find that: - Some folks are scary precise in their estimates. I’d say this is like 10% of engineers. You ask them for an estimate, they tell you, and then it takes exactly that long every single time. In other words, I have confidence that if I ask one of those folks for an estimate, I can take that shit to the bank. - Some folks always overestimate. This is rare. Maybe less than 10% of folks. When I find that someone overestimates, I know that I can take that shit to the bank as an upper bound, which is still useful. - Some folks say they don’t know. That’s fine. Those folks are even rarer, so I don’t have to do anything smart for them. - Most folks underestimate, sometimes hilariously so - they are always one day, or one week, or some other too-short amount of time, away from finishing their multi month effort. That’s fine. Once I know you underestimate, I know that I can take your estimates to the bank as a lower bound. For more than half of the underestimaters, I find that there’s some formula that works: like if Steve says he needs just one more day, he always means he needs five more days. So if suddenly Steve says he needs another week, then I know he probably needs over a month. That’s still useful to me and I’m totally fine if Steve then tells his friends (or HN) how dumb it is that I ask him for estimates. They may be dumb to him but I’ve got my napkin math that turns his BS estimate into something that I can take to the bank. (I don’t actually manage anyone named Steve but I was a Steve as an IC.) So yeah. When I ask you for an estimate, I expect it to be wrong and then I look for patterns in your wrongness. For most people, there’s a pattern that allows me to turn something that looks like a nonsense estimate at first into something I can then plan around. That’s why developers I work with are “expected” to estimate.
  • vsareto 4y ago
    >Some folks are scary precise in their estimates. I’d say this is like 10% of engineers. You ask them for an estimate, they tell you, and then it takes exactly that long every single time. It's possible they are hiding their true skill and sitting inside their comfort zone, so they are really over-estimating based on what they can actually do, but are keeping that truth to themselves. A good reason to do this is to avoid being assigned more work for no real gain and pushing the work-life balance more towards life. This situation annoys some managers when they find out they weren't getting the maximum effort possible from someone for their compensation.
• bob1029 4y ago
  In my experience, the estimate is almost never about an actual, literal target anyone should put on a calendar. It is more of a way for management to slowly develop an understanding of how much cost or anxiety is associated with a thing. The more often management samples you for estimates, the more likely they will start to grasp reality, even if you are wildly-off in most cases. It is traditional for developers to look at this like a binary thing where they're being expected to provide a deterministic outcome at an arbitrary future date. Unless your management is actually incompetent/abusive, they understand how the game works and aren't actually looking for this kind of magic. Once you learn that missing targets is totally fine & acceptable virtually everywhere, life improves dramatically. Another way to look at this: If your work is so easy to predict that you can set detailed targets 12+ months out and deterministically hit them, how much value are you able to provide to your customers?
• emmelaich 4y ago
  Aside, I utterly despise the recent popularity of the "You Have an X/Y Problem" answers in StackExchange.
  • rendall 4y ago
    Is that a trend on StackExchange? So obnoxious. I stopped paying attention to that site years ago.
• r_hoods_ghost 4y ago
  Whenever I read something like, "Software development is not carpentry. Almost everything a developer writes is unique, they have never built that particular thing before. We are not cabinet makers repeating a variation of something we've built hundreds of times before." I just assume that the person is trolling, or a child. Virtually all software developers are building minor variations on thing that have been built hundreds if time before. Sure, maybe not by that particular software developer, but by a thousand others at some point, and half of those have probably stuck their code on GitHub so you can look at how they did it. This idea that software developers are somehow cranking about beautiful snowflakes of such uniqueness that it is impossible to ever estimate how long something will take is nonsense. It is delusional. I really wish as a profession we could get over ourselves and acknowledge that, hey, it is possible to learn from others, that much of what we do is repeatable, and that if you're really struggling with estimating it probably isn't because you're engaged in ground breaking work that has never been done before, but rather that you haven't bothered to think things through.
  • Groxx 4y ago
    I generally think the plumbing analogy is a pretty good one. It even works for estimates! We're often asked the equivalent of "how long will it take you to hook my sink up to my toothbrush for my Thursday home parties" and... well it's nothing new. It's just pipes. Anyone can do it. But estimating it requires an absurd amount of context which is not always available. How far apart are those two things? Is there enough water flow to power the toothbrush, or will you need to upgrade the piping to the sink too? Sometimes the house has everything made of marble and it'll cost millions of dollars to replace the holes you need to make to put those pipes in, though piping itself is only like 30 minutes. Sometimes the toothbrush is a legacy model that only works with deionized water from Uruguay that has been flown within 50 meters of the south pole in the middle of March, do they have a reservoir available for that or can you convince them to just buy a modern one from Walmart to replace it? Does a DWUSPM50 water supplier even exist any more? Oh, you meant only during those Thursday parties? Is there a way we can tell when those are happening, or can they just pull on a lever to change the system? Does GPRD require the pipes to physically separated by 1m when turned off, or is a valve good enough? Why in the world does the customer require all horizontal pipe runs to only go North unless they're underground? None of which is hard, and the plumber doesn't have to build it all in many cases. But how long is it going to take? .... somewhere between an hour and the end of the universe, most likely, unless there's proof the request is impossible. It's not a perfect, beautiful snowflake, but it is a snowflake.
• docflabby 4y ago
  Because the budget is not infinite - there is normally a limit of time or money and it will determine the decision making process. This doesn't mean the project will finish on time or within budget it just enables that part of the decision making process.
• manv1 4y ago
  Let's take a step back to the real question: is the developer upset because 1. they don't know how to estimate, 2. because their estimate is always wrong, 3. they are being held accountable for an estimate that was incorrect, or 4. they feel that it's not their job to estimate the duration of their work? Most people here assume that the issue is #4. However, it's not like they teach estimating skills in school. And the abilities of people vary so much that you'd think estimating would be impossible. But let's go back to the old apprentice/master model for a minute. How much time would it take a master builder to build, say, a classic roll-top desk with a bunch of little drawers out of oak? I think if you surveyed 10 furniture makers their estimates would be within a few days of each other. Then you'd ask them how long would it take for an apprentice to do the same? And I'm sure their answer would balloon tremendously. What's the point of that exercise? Experience matters. When you've done lots of things, and you've paid attention, it's easier to estimate how long it takes to complete things - even if you've never done those things in your life. How long does it take to build an OS? With the right team, it should take about 4 years to build version .9. How long does it take to build a telemetry back-end that scales to a few million clients? Maybe 3 weeks to a month. For someone new who's never touched any of the technologies before? Maybe 4-6 months at a minimum, and that's assuming they're good at integrating things together. So let's get to #1. If you don't know how to estimate, well, you estimate by first trying to figure out the amount of work it takes, then looking at how long it took you to do something of the same complexity/work, then adding some extra time because it's new. You can use your bug tracking system to figure out how long it takes you to fix a bug. What about #2? Well, if your estimate is always wrong you need to find that delta and exploit it. If it took 2 weeks and you said it would take a week, well, try and figure out why. Were you waiting on other teams? Ran into some problem? Couldn't get resources? Or it was harder than you thought? You ran into some unexpected weirdness? Next time, double your estimate. There's a PM rule of thumb that says take your developer estimate, double it, then move it to the next time unit. It actually sort of works when you move it up to the next level ie: include testing/QA, documentation, training, deployment. #3. Are you really going to get fired because you gave a bad time estimate? Then you either need to get better at it or leave. The fact is, anything of any complexity is going to require more people to do, and more people = more time = worse estimates. But it's really up to you to keep people up to date. If you estimate 3 months and you're not even close after a month, well, maybe it's time to tell people and reset expectations. But what the heck are you doing that requires 3 months of work?
• justizin 4y ago
  sometimes estimates are useful for deciding what not to do.. “oh, that’s gonna take 6 months? we won’t need it by then, let’s do something else.”
• baxtr 4y ago
  Because estimates show that you’ve actually thought through the task. It’s a forcing function. Estimates aren’t the issue. People using estimates against you are.
• kagevf 4y ago
  Toyota, where Lean came from. Doing estimates to put together a car sounds like it would be straight-forward. Doing estimates for R & D, not so much. I think software development falls somewhere in between those 2 extremes. We have some knowable quantities, but also some unknowns. We can't really estimate the unknowns reliably, but we can do something like a "timebox" to see how much we can figure out. Meaning that we need time up front, just so that we can come up with an estimate.
• beastcoast 4y ago
  I’m a big fan of AMZN’s approach: - make an operational plan (OP) for the entire year, which sums up all the HC on your team - figure out your goals for the year - have some senior engineers estimate those goals in # of HC (usually 0.5 HC is the lowest granularity) - add up the HC, prioritize the goals and figure out the cut line against your budget for the year - when the new year rolls around, start execution. Launch dates are usually set by quarter, with the majority launching by Q3 - individual teams have complete leeway to use whatever project estimation techniques they want. It really doesn’t matter at all. Even waterfall is “fine”. All that matters is whether they can deliver the goals they signed up for in their OP. - if a goal goes off the rails, report a “traffic light status” (red/yellow/green) and path to green, and engage leadership accordingly to reset expectations. People accuse this process of being too waterfall / unagile, but it’s actually really helpful in centering the deliverables with business value, while giving teams extreme autonomy to achieve those goals. Mature businesses think in terms of quarters and bottom lines, not sprints and story points.
  • justeleblanc 4y ago
    Why are you referring to the company by its stock mnemonic?
• drojas 4y ago
  Estimations are useful for developers and management. It helps developers prioritize their time and propose more efficient approaches. It helps management track projects and make decisions more efficiently. Even an open-ended problem has to be scoped into a time-boxed "spike" first that would result into concrete stories which would be sized in story points. Nobody likes to give estimates because it feels like an unfair commitment. These are the rules I follow myself based on my own learnings and advise from others. 1. If I can't feel sure about an estimate in story points then I prepend a time-boxed "spike" to solve that first. 2. Always consider "extra" tasks like tests, data migrations, etc. in the estimate. 3. If my estimate looks bigger than what I can do in half of a sprint if you do scrum then I break it down to smaller stories so I have less risk to have the story rolling over. 4. Add about 20% of padding to all estimations. 5. If you take notes in the story/tickets about all the things adding to the estimation besides common discussions about the work, then you'll get more and more comfortable with your estimations over time.
• leepowers 4y ago
  OP is working in a dysfunctional workplace and has conflated that with "developer estimates are bad": > 1. Give a very wide estimate with a lot of padding > 2. Get pressured to be more accurate and to bring the estimate down > 3. Get pressured to work unpaid overtime to meet that estimate > 4. Watch management get congratulated by upper management for running a tight ship Imagine I had plumber at my house and he gave an estimate of 3 to 4 hours to replace a rusted pipe. And I responded with "I think it should only take you 1 hour". He would look at me like I was crazy. That's because trying to substitute my layman's estimate for a professional estimate is crazy. OP is providing estimates - that's a reasonable ask. The problem is management is ignoring the professional estimate and using their position to substitute in their preferred estimate. OP is being used to launder management's expectations. So of course they're patting themselves on the back. If the plumber ignored his own professional experience and only charged me for 1 hour of labor I would think of highly of myself as well, even though in reality I had no idea what I was talking about. The solution is to set estimates that you can explain and justify. If management ignores your professional opinion you need to make it clear it's their decision and not yours. If you don't respect your own opinion no one else will.
  • asdff 4y ago
    I think what is hard with a lot of tech is that developers are often not plumbers. We are not encountering similar sets of problems nor are able to use similar solutions or even refer to familiar tooling all of the time. It's more akin to when the plumber crawls below your house with nothing more than a flashlight, then recoils in horror that your sewer is plumbed in 200 year old rotten wood pipe, then they start digging and hit more pipes that aren't on any map and shouldn't be there, then things get expensive and timelines enter the unknown as the problem gets seemingly bigger the more of it that you solve. Of course the client never sees this, they think you just twist a wrench, so we have these deadlines and talented people burning out over the stress they cause them.
    • mynameisvlad 4y ago
      > We are not encountering similar sets of problems nor are able to use similar solutions or even refer to familiar tooling all of the time. Frankly, yes we are. There’s only so many ways to solve a problem and there’s only so many problems to solve in a particular field. A senior engineer should have had enough experience to at least have a high level understanding of what is going on, and to correlate that experience with approximate work. If that’s not possible, the work is just not scoped down enough. A team of engineers, given their combined experience and business knowledge should pretty easily come up with a story point estimate based on existing completed work. And that’s the entire point of the refinement and estimation process: getting enough information about a piece of work, then working together to come to a decision on an estimate. Will that be right all the time? No. But that doesn’t mean the value is useless, it provides plenty of information on if a piece of work is small, medium or large, as well as if it’s expected to take a few hours, days or weeks. And who better to come up with that number than the people actually working on the issues?
• eschneider 4y ago
  Reasonably accurate estimates aren't that hard to get if engineers and management REALLY want them. Just remember that estimating a project is a project unto itself. You just need to break things down into small bits that can be accurately estimated and be honest about the bits you don't know enough to estimate and dig down into those bits until you know enough to accurately estimate them. It's not easy and it takes time. I used to do a lot of fixed price work and you'd live or die based on how well you could do this. Let me tell you, nothing is worse than busting your ass on a project for six months only to lose money on it. Ugh.
• black_13 4y ago
  [dead]
• NewEntryHN 4y ago
  The actual answers to OP's question is that management needs to know: - how much resource to allocate to the task - variations of the estimates in function of variations of the scope In my experience, "ballparks" estimates are sufficient for this exercise, and precise estimates are just resource-tracking leading to the issues described by OP.
• lowercased 4y ago
  Worked in a position as a nominal 'team lead' for a couple years. Small group, as they got funded and grew, more management and ceremony kept creeping in, and... we had more planning/estimating meetings. I was asked a few times "when will this be done? We need to know when X will be done". So... already, I'm bristling because we don't have a shared definition of 'done'. My pushback was... probably seen as not helpful/aggressive/whatever, but I responded with something like: "I can't tell you specifically, because I don't have control over all the people and processes that get us to 'done', meaning it's tested/reviewed/deployed". At that point in time, I already had code developed locally with tests, and had pushed up something sitting on an ephemeral dev branch for others to poke/test/verify. "What do you mean you can't be specific? We need a date". "OK... Oct 28" (at the time, it was 2 calendar weeks away). "Well... I can't trust anything you say at this point - I'm going to say Nov 9". Pissed me off to no end because... why ask if you turn around and say "I do not trust anything you say"? I tried explaining further: "We have to have an internal code review, some internal testing, some testing with the client on this feature, some testing of it merged in with everything else, then a deploy. All of these involve other people. I've asked multiple times for the people responsible for these to pick up the task and give me any necessary feedback. 3 of them have told me 'Not now, MrX told me ABC is my highest priority', so... short of you, MrX, telling them to cooperate with me ahead of the other items, I have no ability to move this forward. It's been ready/sitting/waiting for 3 days already, but without some explicit authority from you telling other people to take this task seriously, and prioritize it and cooperate with me, I can not give a date when it will be 'done', because I don't control 'done'. The entire group does, and they're all politely telling me it's their lowest priority, on your order." I got some reply along the lines of "now you're just being argumentative and pedantic!" Me: "I could roll it out now - I'm relatively confident in the code, docs and tests I have in place, but our process is steps ABC, then XYZ, and other people who are not me are tasked with that. If I roll it out now, I'm violating the group process/agreement, and this will be seen as aggressive, or passive-aggressive, or 'non-team-player', etc. So... it could be 'done' tomorrow, but not through normal processes." "No, we have processes in place for a reason, we have to follow those". Me: "OK... so, if my code is dependent on people who can deprioritize or skip over or ignore any requests I ask of them (many were documented in tickets as 'waiting on personX')... how can I both follow the process, and give you a specific date when something will be 'done'? I can not." I was so frustrated here because the 'process' was brought in to 'make things better', but it spread everyone too thin. We (group of 4-5) had routinely been missing estimated delivery dates for months - it got worse after new processes, not better (but we put more in jira, so there were nicer charts showing how bad it was getting week to week!). We just went around in circles for another 5 minutes or so then I left the meeting. It was a constant state of feeling like I'm being talked down to, and "I can't trust anything you say". I get it - people need some degree of estimates/delivery dates. Extra 'agile' processes along with spreading people too thin, siloing people, then ignoring the day to day impact - none of this was good. This was a few years ago - I've thought some more about how I might handle that differently if it comes up again, but I keep coming back to "avoid projects/teams/processes like that again" as the easiest path. I'm not sure there's any productive way to get out of the logical 'rock and a hard place' that ended up being (from my POV). It boiled down to "give us a specific date on something which requires multiple other people who you have no control/authority over, and whom I've also told to ignore you and/or deprioritize your requests". The only options seemed to be a. give me control over those other people needed to follow the process b. bring in more people to help follow the process c. allow me to bypass the current process FWIW, someone else got wind of this on the client end and we collaboratively did option C a few days later, and it was just rolled out (to the client's satisfaction) well before the end of October.
• the_gipsy 4y ago
  In my current company we don't estimate, and that's the best perk I've had, ever. It removes so much pressure and anxiety and negative feelings.
  • reikonomusha 4y ago
    Where is accountability introduced? Who makes the judgment that something is taking too long?
    • the_gipsy 4y ago
      We're accountable on an individual level with our direct managers. The team lead, his boss, and product managers make judgements of priority when something takes longer than expected.
• deleted 4y ago
  [deleted]
• tailrecursion 4y ago
  Software is a vast field and we do different kinds of work. Some work is easier to estimate than others. Estimating TTC for "make a reputation system for a social network" is probably going to be harder than the same for a typical Oracle app. Mostly because the former involves some science and engineering and not just programming. But that's the point I'm trying to make: SWEs are asked all the time to solve hard problems, not just code from a detailed spec. At various times I've been asked to design a CPU, write a C compiler, invent technology to extract simple factoids from text, and make a spellcorrector for web search. Incidentally, the approach to schedules was sometimes reasonable and sometimes unreasonable. Smaller companies tended to be less reasonable. Such tasks are very different from UI heavy work or a typical database application, and are more difficult to estimate. Those persons writing compilers or improving web search indexing are not the same people talking about user stories. If you believe developers need to be professional and schedule their work, you're in the majority but you may not be doing truly interesting work. [Edited to say "Software" at the beginning instead of "Software Engineering".]
• haha69 4y ago
  Lots of good answers which add a lot more value than mine. I'd like to answer it with an xkcd comic - https://xkcd.com/1425/ https://xkcd.com/1425/ that hopefully gets the message across as to why we estimate.
• asdff 4y ago
  I can see of course why clients want deadlines, but I can't help but imagine that deadline-based work is somehow antithetical to who we are as humans. We are supposed to go out and make what we can of the daylight, then retire satisfied that any work towards foraging or the homestead is good work. You don't set out to forage x amount in y days; you forage for a period of time and see what you end up with by the end. There is no deadline or quota to meet for this sort of work, nor can one provide any estimates because things are often well out of your hands, controlled by the forces of nature. Not all that many jobs grant you the opportunity to work like this in the modern knowledge worker domain, unfortunately, so we are constantly stressing ourselves out with these self imposed "deadlines" that go against the sensibilities of how our species evolved. Of course you end up grey haired and stressed out before long, we aren't built for this. Maybe a job that allows you time to venture into the woods and come back at your own pace so to speak is the kind to have for a low stress life, perhaps one a little better suited to our underlying biology.
• chrsw 4y ago
  I rarely see projects finish on time and on budget. I don't think I'm unlucky. I wonder who is at fault for this, developers and engineers or project management. Or both.
• austinjp 4y ago
  I've been on all sides of this issue. Producing code, managing teams, providing estimates, negotiating deadlines, pre-sales, small teams, large orgs, the works. Deadlines and estimates are all smoke and mirrors, all bullshit. Sometimes that can be fine, but it becomes a problem when the stakes are high (for some definition of "high") and when negotiating power is removed from some group -- and frankly that group is always the one shovelling coal in the engine room. I'd love to see the coal-shovellers in a position to apply as much pressure to the sales/whatever teams and upper management. I mean, it would surely be a disaster, but an entertaining one. Milgram's prison experiment all over again.
• OJFord 4y ago
  I wish I was asked to estimate a time deadline. I'd prefer that I think to the current situation where we pretend to estimate 'complexity', and then say we can only fit X amount of complexity in a two week sprint, or it's not a very complex ticket why's it taking so long. Not that I want to be held to time-estimates, I just think at least call it what it is. You can't schedule your sprint on time, and the amount of points in it on complexity, you have a dimensional error.
• 8note 4y ago
  You can reframe estimation tasks to identifying where there's uncertainty, and what the PM should prioritize to ensure the project is successful. Your estimates are prioritization inputs and tasks for the PM to do, managing said PM. Gannt charts do this well, and you can apply rhetoric to your arguments by setting some tasks to be much much longer than others. The reader will see those items as the most important and influential for affecting the total time
• adverbly 4y ago
  Context is everything. 1. How important is it that we get an estimate? Things take the same amount of work with or without the estimate, so how bad is it actually if we don't know how long something will take? And no - a feeling of general anxiety among management/leadership around "not knowing" DOES NOT count as an actual cost! If I can't handle uncertainty, that shows a lack of maturity on my part. If the estimate is not critically important due to factors external to the company, consider using an appetite instead(https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-variable-scope https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-varia...). 2. If I truly need an estimate, the next question is how difficult is it to provide an accurate estimate? Nobody can estimate how long AGI or flying cars will take. If we need a new field on a form and in the DB - something the team has done many times before, I would require an accurate estimate from the engineers, and hold them accountable if they miss the target. However, if I NEED an estimate for a very difficult to estimate task, it is a RED FLAG that the company is at significant risk. Rather than push the team to provide a more accurate estimate, leadership/management should instead focus on strategic moves or contingencies to mitigate risk. If strategic moves/contingency plans are not realistic, the next preference would be to play it safe: rather than waiting for the estimate, start work immediately and redirect/focus additional resources on the task until the risk has been lowered(get progress updates instead of estimates). If we can't actually start work, we need to have a long and hard think about our core business and work practices because the process is putting massive stress on ICs by making them guess at things which may be outside of their control, leading to decreased performance and increased attrition.
• McSwag 4y ago
  I feel I could pick out exactly who the developers are, the managers who used to be devs, and the PMs from these comments with a pretty good success rate.
• mytheory 4y ago
  Since no one mentioned it, I have a good news for you: it's a sweet spot between what a project manager needs and a team member needs, it's called a PERT estimate. When asked to do an estimate, give your optimistic estimate, realistic estimate and pessimistic estimate. This allows for a better idea of the risk and padding needed for this task (you don't need to add a buffer in any of those numbers) and the manager can use that to calculate a weighted average (very simple formula that you can find online). It's in the PMBoK, so if you have a project manager, he/she should know about it.
• taylodl 4y ago
  It's been this way for over 60 years. You'd think we'd have formalized an estimation process by now. Here are some tips I've developed over the years: - Estimate in days, not hours - Don't forget testing, especially end-to-end testing - Don't forget project execution overheads (PM's, BA's, stakeholder meetings, etc.) - Don't forget deployment overheads, if you have them Finally, all stakeholders should understand that initial estimates are a Rough Order of Magnitude estimate, i.e. the actual cost will be -50% - 150% of the estimate. The investment decision needs to be made at 150% the cost, for that's what they project may actually cost and if that doesn't make sense to invest then you can nip the project in the bud right now. That's the whole idea behind a ROM estimate. Death Marches are a symptom of organizational incompetence, and yes, many organizations are incompetent and destined for eventual failure.
• more_corn 4y ago
  Why should you be expected to estimate how much time it’ll take you to get across time for your doctor’s appointment? Just head over there whenever. I’m sure everything will work out in the end.