8 ms·

> The buyer has to make commitments Not surprised this discussion devolved into this bizarro world point so quickly. The developer says “there are too many unk

> The buyer has to make commitments Not surprised this discussion devolved into this bizarro world point so quickly. The developer says “there are too many unknowns to provide any sort of estimate”. The manager retorts “but we need estimates!” As if they expect the developer to say “oh, you need them? You didn’t say that. In that case, the unknowns are now known and it will take four days, three if you remove this inconsequential detail that nobody cares about”. Unfortunately this bit of illogic is so common that I know it’s a waste of time to argue, so I’ve learned how to figure out what they want the estimates to be, give them that, miss them (just like everybody else does), and then get to work on actually providing the feature.

SergeAx 4y ago
The original question was "Why are developers expected to estimate tasks at all?" @benjaminwootton gave perfectly sane answer to that question. HOW developers should make their estimation is a totally different question, but it is not some arcane knowledge, and it should be an everyday craft for every mid-level engineer. First of all, we are doing those tasks by hundreds through our careers, so an easy way is to remember how long similar tasks took us last 10 times an produce a bracket, like in "from 5 to 8 working days, let's say 10 to be sure". Every business person will be happy with that answer. OP says that every engineering task is unique as a piece of art. This is BS, IMO, except for the very junior engineer. Most of the time business wants some well-known and hundred times done things they see their competitors do. All the uniqness stems from particular codebase. If your codebase is a mess - you are in trouble, but it is you problem, not the general problem of software engineering. In case I have some really unique task, what I should do is to say: "I cannot estimate this right now. Give me two days and I will get you an estimation". In those days I decompose the task into smaller, and divide those smaller tasks into "well known" and "unknown". Then I imagine (or even draw) a trivial Gantt chart and will have my estimation. It is also totally normal to change your estimation during the work. You just should do that the moment you see a problem, not at the day of the deadline.
sixothree 4y ago
For these I like to say "by the time I can give you an accurate estimate, I will be done with the work." Seriously though. It's always a time tradeoff. How much time do you want an expensive developer investigating how long this problem will take. Will they learn something they can use during development. I always follow up my above quote with the unknowns and how hard I think they really are; what are the possible risks; _and_ I include the experience of the developers working on the problem; our ability to bring in other devs who understand this better etc etc. I like to make sure whoever is quoting this problem out understand everything as well as we can in the given amount of time.
- mynameisvlad 4y ago
  Is this not what estimating and refinement means to developers? I’m always pulling a number out of my ass, but that number is generally informed by current and past work, unknowns, and a “gut feel”. If that number is too high, then that’s a sign to management that the work needs to be changed. The only way to determine that is to estimate it then make that call.
  - hgsgm 4y ago
    That's relevant for order of magnitude only, and only for "body sbop" work that is the same as previous work. And only works if management wants an estimate. More commonly, management wants a lie they can tell the client.
    - mynameisvlad 4y ago
      > and only for "body sbop" work that is the same as previous work. That’s absolutely preposterous. As a senior engineer, I have seen enough that I have at least a high-level idea of what most of the dev tasks and stories I’m estimating are. I don’t always have the specific details that may change the estimate, but I also have a whole team of other people who have seen even more things and can inform that opinion. The point of refinement sessions is to share this information with everyone else so an estimate can be created and if needed, tasks can be better defined, split up or merged. > And only works if management wants an estimate. More commonly, management wants a lie they can tell the client. Wat? Estimates is used for plenty of reasons that have nothing to do with external clients. How do you think your manager, their manager, etc knows what is going on and approximately how long it’s going to take? They’re going to be far more disconnected from the work than the people doing it day to day, so they would generally have no clue how long something is estimated to take without someone telling them.
WastingMyTime89 4y ago
> The developer says “there are too many unknowns to provide any sort of estimate”. You are misunderstanding your job. You are a subject expert and paid accordingly. Answer with what the unknowns are, an optimistic and pessimistic take on them, what you could do and how long it would take to lift them. If you don’t, your boss is going to ask you for exactly that in a roundabout way and micromanage you because you are forcing them to do your job. It still baffle me than approximately half of developers don’t understand things which are obvious to any seasoned blue collar worker.
- mumblemumble 4y ago
  Blue collar vocational training is more mature than software development vocational training. It's typically taught by people who have professional experience, and there may even be an apprenticeship period where people are explicitly learning from an expert in their profession while on the job. In software, on the other hand, we often have most training being taught by professional academics who do not understand and are not qualified to teach the parts of the job that don't have a straightforward academic analogue. Combine that with a business environment where things like budgets and cost control are often only theoretical, and all but the most gross liability for defects due to poor workmanship has been waved away by EULAs, let it marinate for several decades, and... yeah. Not only do people not know these things, but I'm not entirely clear on how or why they should be expected to learn them, either.
- Scarblac 4y ago
  I mostly agree, but if it's a technology I've never worked with and I'm asked to do something I've never done before, I'm not an expert. That doesn't stop them asking for estimates, which turn into deadlines.
  - bluedino 4y ago
    That's a special case then.
    - re-thc 4y ago
eapressoandcats 4y ago
I don’t see how it’s unreasonable that someone would want to make plans based on the development velocity of software. Just because it’s actually hard to estimate some things accurately doesn’t mean it’s not valuable from a business perspective. The original post was someone saying that they should never be asked for estimates because every single thing they make is a unique snowflake of unknowable complexity, which is absurd. There are definitely features which an engineer can easily estimate delivery timelines on, and even knowing ballparks like “this is hard (as in weeks)” or “this is easy (as in hours/days)” is super valuable to communicate to actual business stakeholders. In a healthy culture it should be possible to have a back and forth about how accurate an estimate is likely to be, but when engineers insist that all estimation is useless you can imagine why other stakeholders may lost trust.
alkonaut 4y ago
This is why it’s a good idea to have ranged estimates. If a simple known thing with zero unknowns has maybe a 200% margin (1-3 days) then a more unknown task can have 10x as wide margin like 1 to 20 days. As a developer I never get “that’s a useless estimate we can’t prioritize based on that/tell the customer that”. It’s a perfectly good estimate. It tells everyone there is a lot of uncertainty. The low lower bound indicates there is a chance it might turn out to be cheap (so maybe worth taking a gamble and trying it and giving up). The big variance indicates it could/should be given some time to prep/investigate in order to narrow the estimate. When there are unknowns, make a wide estimate. Convey the uncertainty. If the unknowns are ridiculous, make a ridiculous estimate. Even “5-200 days” is useful because something else with less uncertainty can be chosen instead.
- kelnos 4y ago
  The SO question addresses this, though: after giving an estimate with a range, the developer is pressured to narrow that range, mainly by pulling in the farther-out date in the range, and then the developer is blamed when the project inevitably comes in late because of that. Maybe the solution here is "stick to your guns", but that can have negative career implications.
  - alkonaut 4y ago
    That’s perfectly expected. But the key is: narrowing the estimate isn’t free. You can’t pull a different estimate out of thin air. And zero people will expect it. The developer needs to say “I can say 10-100 days right now in this meeting, but given just 1 day of investigating, I’ll narrow the estimate range by an order of magnitude”.
    - deleted 4y ago
      [deleted]
- InexSquirrel 4y ago
  I agree with this sentiment. I'm running through a similar situation now, where I'm somewhat adjacent to a client and a dev team. The client has a list of tasks he wants done, and he'd like banded estimates for the effort the dev team thinks it will take to complete each. The developers are obliging, but one of them complained to me privately "why doesn't he just give us 2 months of budget and we'll get through as much as we can?" - which is an interesting statement. From the developer's perspective, this is ideal. They are very good and work hard and have integrity, so I'm sure something like that would work, from their perspective. They can just 'go' and get stuff done. From the client's perspective though, it just raises a bunch of uncertainty. He wants to know what he could get out of his 2 months of development budget. If one task took all 2 months, and the others (15 in this case) didn't get done, is that OK? What if some important task wasn't that much effort? You'd potentially want to priortise that over a bigger item. Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships.
DeathArrow 4y ago
> Unfortunately this bit of illogic is so common that I know it’s a waste of time to argue, so I’ve learned how to figure out what they want the estimates to be, give them that, miss them (just like everybody else does), and then get to work on actually providing the feature. I do that and I've become exceptionally good at blaming the business persons for the outcome, making them admit their guilt in public and all that in what seems a friendly, positive and constructive manner and using business motivation and explanation. They never understood what hit them. Every programmer can do that if he or she learns a bit of psychology.
- meghan_rain 4y ago
  Can you elaborate?
  - DeathArrow 4y ago
    I just confront business people with the results of their choices in a civil and polite manner. If some manager made a promise to a client out of his/her ass without asking us, and if the PO pressures us towards meeting an unrealistic time-frame, when that explodes I just explain in a public meeting where upper management and all stake holders take part why it was wrong to promise that, using arguments and business considerents because bussineses people don't care about tech considerents. It usually results in that person admitting in public their mistake and even saying they are sorry. I don't do that to humiliate people but to teach them to ask the team implementing the feature to estimate or to say if that feature is even reasonable or possible given current state and resources.
jfengel 4y ago
The estimates are useful even if they're wrong. Not all managers realize that, so they ask the question badly. And they never teach it to programmers. The estimates aggregate to a number more accurate than each individual. The manager cares more about the sum total than each individual one. Many can even slip without affecting the end date. This isn't so hard, if management and developers didn't treat each other as enemies. Each can get wrapped around the axle concerning each deadline, rather than the real goal of allocating resources across the entire scope.
iblaine 4y ago
It’s monumentally frustrating to be forced to give estimates too soon in the planning process. The compromise, I hope, is to end up in a place where most of the problem is known and some is unknown, and you get there by breaking down the original problem. Leave it up to the “buyer” to digest your best estimate into their planning process.
UncleMeat 4y ago
The response to "there are too many unknowns to provide any sort of estimate" shouldn't be exactly "well, we need estimates." But "okay, just do whatever" is also not a working outcome. Software is weird, yes. But other disciplines are able to provide useful planning information. Why are we unable to do that?
- lazide 4y ago
  Most other disciplines have this exact same problem. Construction contractors for instance, are notorious for it. The difference is, the law says if a contractor signs a contract to do something at x price, they HAVE to do so or suffer consequences. So contractors go broke/bankrupt, lose their licenses, or figure out how to bid correctly enough they can either weasel out of it if it goes sideways or they have enough wiggle room to deal with the inevitable problems. Software Engineering Consultants have the same situation. But directly employed software engineers are in a different position of course. One thing that typically makes this worse, is the implicit assumption that planning/quoting/estimating is ‘free’ work, and since it CAN make things easier to deliver, therefore we should do more and more of it as, since it’s free, it will solve the problem no?
  - UncleMeat 4y ago
    Other disciplines have problems with slippage, but none of my friends who are in physical engineering fields insist that they shouldn't even have to provide estimates in the first place.
    - lazide 4y ago
      Of course not, their protected place comes with conditions like giving estimates (and being held to them). And their disciplines involve massive capital outlays which can’t be refactored in a cost effective way, or at all really. Not defending the ‘no estimate ever’ approach, it doesn’t work. They are different though.
- jiggawatts 4y ago
  Really, they can, can they? Even the bespoke, one-off projects with unknown unknowns? Tell me, how accurate were the estimates for the launch date of JWST? I’ll wait here while you look up how many times and how many years that “slipped”. I bet some dumbass NASA manager asked the team to schedule the launch date back in the 1990s.
tsgagnon 4y ago
Unfortunately this bit of illogic is so common that I know it’s a waste of time to argue, so I’ve learned how to figure out what they want the estimates to be, give them that, miss them (just like everybody else does), and then get to work on actually providing the feature. It gets even worse when you are in a line of work where the estimates are part of some kind of sales pipeline. Then you aren't just estimating based on effort required, but also against a likely number that the customer will ever agree to.
Buttons840 4y ago
App idea for tracking projects: Each individual developer can anonymously indicate how far along they believe a project is. For example, Developer A thinks the project is 60% complete, but Developer B thinks the project is 30% complete. Use algorithms to predict the completion date. However, I don't think this idea would be very popular because it removes the manager's ability to control the presentation and play politics.
- deleted 4y ago
  [deleted]
idopmstuff 4y ago
See in this case the manager has done a bad job, but the developer has also done a bad job, both in the exact same way. The correct solution here isn't just to insist estimation is impossible and be offended that someone would ask for it - that just misunderstands how businesses work. The correct thing is for either of those parties to say, "Okay, I understand it's not estimable at the moment. What are the steps that we need to take in order to get a reasonable estimate?" A good PM will do this, but where there is a bad PM, a developer can step in and say the same thing. In your scenario, "The developer says “there are too many unknowns to provide any sort of estimate”." What the developer could say is, "There are too many unknowns to provide any sort of estimate - let me give you a few examples. <examples>. What I can do is come back to you after <amount of time> with a list of the unknowns and an explanation of the work required to evaluate them, so that we have enough information to estimate. Once you have that list, then you can decide if we want to proceed with the work to understand those unknowns." I totally understand why developers get frustrated when they're asked to give estimates for things that can't reasonably be estimated with the current information available. But the flip side is it's also very reasonable for PMs to get frustrated and ignore developers who insist that estimation is an impossibility, because that's virtually never true - maybe it's impossible to do now, but there is a path to make it possible. If you work proactively to expose that path to the PM, it'll generally result in everyone being happier.
- myshpa 4y ago
  > There are too many unknowns to provide any sort of estimate - let me give you a few examples. What I can do is come back to you after amount of time with a list of the unknowns and an explanation of the work required to evaluate them, so that we have enough information to estimate Sometimes we don't know what we don't know. If we don't know what we don't know now and if we don't know what we'll find we don't know later, then we don't know how long we will need until we'll know. Uff. Sorry. If I had more time, I would have written a better comment.
  - idopmstuff 4y ago
    Let's put it this way, then - either you're totally incapable of building whatever we're talking about under any circumstances, or, even if it has unknowns, there are steps you can take in the right direction to get started and move things along. You will learn things that will help you understand the problem better along the way. If it's the latter case, then a good developer can describe the immediate steps they'll take and what questions they expect to answer. Whatever the case, there is always some concrete next step you can take to which you can assign a reasonable estimate of time. That might just be that you'll spend one day perusing some documentation, and the only outcome you expect from that is that you'll develop a reasonable enough understanding of how large/complex the documentation is, such that you can come back with an estimate of how long it will take to find and carefully read all the relevant sections of the documentation. That's totally fine - if it's the sort of wildly unknown problem that you're describing, then I recognize we'll have to take steps to understand the problem. There's still never a case where it's impossible to create an immediate plan of action and understand roughly how long that will take (unless you are simply unqualified to take on the problem). I had a boss loved the phrase, "a date for a date." He just meant that if you can't give me a date for when the thing will be done, then you need to give me a date for when you can give me a date for when the thing will be done. Can't do that? Date for a date for a date. However many levels we have to go, you're not getting out of whatever meeting we're in until you can give me a date by which you'll be able to come back and give me another date.
awesome_dude 4y ago
No, hard no. In my experience good communication solves this every time. MGMT: We need an estimate ENG: I have several unknowns MGMT: We really need an estimate ENG: This is my rough estimate, but be aware that the unknowns could change this drastically MGMT: Ok, what do you need to get a firmer estimate. And so on. As a project progresses, the communication between ENG and MGMT is crucial to ensure that MGMT are aware how those unknowns are affecting the project, MGMT will decide at every juncture if the project is worthwhile to continue to invest resources into it (assuming they avoid the sunk cost fallacy)
doctor_eval 4y ago
Estimates are theatre. It’s not even theoretically possible to provide accurate estimates for anything but the most trivial project, yet here we are. As an industry we just seem incapable of coming up with any other way of negotiating and running projects.
Fire-Dragon-DoL 4y ago
You can say this, but when a plumber or an electrician comes home, they are always expected to provide quotes and duration of work
mewpmewp2 4y ago
The fair thing to say is that there's something like 80-90% chance that this will take X time, 99% chance that it will take less than Y time. This would allow for planning, prioritising and is the most accurate communication we can achieve.
- wruza 4y ago
  The best thing to do is to define tradeoff ranges and set the deadline, so that developers could try an optimistic path, learn what’s wrong with it halfway, and then choose a tradeoff that both seems not that bad enough and, when it fails, leaves time to rethink and use another tradeoff which is even good now, in a sense. Because that’s what we do either way. Round numbers from ass make no science to plan and prioritize upon.
antman 4y ago
A general framework is that on each decision, including architecture, cost, time one at least adds the following: 1. Assumptions (including soft such as who will actually do it, resources are not equally relevant or productive) 2. Constraints (as agreed by stakeholders) 3. Risks 4. Clear scope 3. Alternatives and why they were not preferred Business should be aware and own the uncertainties, or else the system gets biased towards sales people offering vaporware.

SergeAx 4y ago

The original question was "Why are developers expected to estimate tasks at all?" @benjaminwootton gave perfectly sane answer to that question. HOW developers should make their estimation is a totally different question, but it is not some arcane knowledge, and it should be an everyday craft for every mid-level engineer. First of all, we are doing those tasks by hundreds through our careers, so an easy way is to remember how long similar tasks took us last 10 times an produce a bracket, like in "from 5 to 8 working days, let's say 10 to be sure". Every business person will be happy with that answer. OP says that every engineering task is unique as a piece of art. This is BS, IMO, except for the very junior engineer. Most of the time business wants some well-known and hundred times done things they see their competitors do. All the uniqness stems from particular codebase. If your codebase is a mess - you are in trouble, but it is you problem, not the general problem of software engineering. In case I have some really unique task, what I should do is to say: "I cannot estimate this right now. Give me two days and I will get you an estimation". In those days I decompose the task into smaller, and divide those smaller tasks into "well known" and "unknown". Then I imagine (or even draw) a trivial Gantt chart and will have my estimation. It is also totally normal to change your estimation during the work. You just should do that the moment you see a problem, not at the day of the deadline.

sixothree 4y ago

For these I like to say "by the time I can give you an accurate estimate, I will be done with the work." Seriously though. It's always a time tradeoff. How much time do you want an expensive developer investigating how long this problem will take. Will they learn something they can use during development. I always follow up my above quote with the unknowns and how hard I think they really are; what are the possible risks; _and_ I include the experience of the developers working on the problem; our ability to bring in other devs who understand this better etc etc. I like to make sure whoever is quoting this problem out understand everything as well as we can in the given amount of time.

mynameisvlad 4y ago
Is this not what estimating and refinement means to developers? I’m always pulling a number out of my ass, but that number is generally informed by current and past work, unknowns, and a “gut feel”. If that number is too high, then that’s a sign to management that the work needs to be changed. The only way to determine that is to estimate it then make that call.
- hgsgm 4y ago
  That's relevant for order of magnitude only, and only for "body sbop" work that is the same as previous work. And only works if management wants an estimate. More commonly, management wants a lie they can tell the client.
  - mynameisvlad 4y ago
    > and only for "body sbop" work that is the same as previous work. That’s absolutely preposterous. As a senior engineer, I have seen enough that I have at least a high-level idea of what most of the dev tasks and stories I’m estimating are. I don’t always have the specific details that may change the estimate, but I also have a whole team of other people who have seen even more things and can inform that opinion. The point of refinement sessions is to share this information with everyone else so an estimate can be created and if needed, tasks can be better defined, split up or merged. > And only works if management wants an estimate. More commonly, management wants a lie they can tell the client. Wat? Estimates is used for plenty of reasons that have nothing to do with external clients. How do you think your manager, their manager, etc knows what is going on and approximately how long it’s going to take? They’re going to be far more disconnected from the work than the people doing it day to day, so they would generally have no clue how long something is estimated to take without someone telling them.

WastingMyTime89 4y ago

> The developer says “there are too many unknowns to provide any sort of estimate”. You are misunderstanding your job. You are a subject expert and paid accordingly. Answer with what the unknowns are, an optimistic and pessimistic take on them, what you could do and how long it would take to lift them. If you don’t, your boss is going to ask you for exactly that in a roundabout way and micromanage you because you are forcing them to do your job. It still baffle me than approximately half of developers don’t understand things which are obvious to any seasoned blue collar worker.

mumblemumble 4y ago
Blue collar vocational training is more mature than software development vocational training. It's typically taught by people who have professional experience, and there may even be an apprenticeship period where people are explicitly learning from an expert in their profession while on the job. In software, on the other hand, we often have most training being taught by professional academics who do not understand and are not qualified to teach the parts of the job that don't have a straightforward academic analogue. Combine that with a business environment where things like budgets and cost control are often only theoretical, and all but the most gross liability for defects due to poor workmanship has been waved away by EULAs, let it marinate for several decades, and... yeah. Not only do people not know these things, but I'm not entirely clear on how or why they should be expected to learn them, either.
Scarblac 4y ago
I mostly agree, but if it's a technology I've never worked with and I'm asked to do something I've never done before, I'm not an expert. That doesn't stop them asking for estimates, which turn into deadlines.
- bluedino 4y ago
  That's a special case then.
  - re-thc 4y ago

eapressoandcats 4y ago

I don’t see how it’s unreasonable that someone would want to make plans based on the development velocity of software. Just because it’s actually hard to estimate some things accurately doesn’t mean it’s not valuable from a business perspective. The original post was someone saying that they should never be asked for estimates because every single thing they make is a unique snowflake of unknowable complexity, which is absurd. There are definitely features which an engineer can easily estimate delivery timelines on, and even knowing ballparks like “this is hard (as in weeks)” or “this is easy (as in hours/days)” is super valuable to communicate to actual business stakeholders. In a healthy culture it should be possible to have a back and forth about how accurate an estimate is likely to be, but when engineers insist that all estimation is useless you can imagine why other stakeholders may lost trust.

alkonaut 4y ago

This is why it’s a good idea to have ranged estimates. If a simple known thing with zero unknowns has maybe a 200% margin (1-3 days) then a more unknown task can have 10x as wide margin like 1 to 20 days. As a developer I never get “that’s a useless estimate we can’t prioritize based on that/tell the customer that”. It’s a perfectly good estimate. It tells everyone there is a lot of uncertainty. The low lower bound indicates there is a chance it might turn out to be cheap (so maybe worth taking a gamble and trying it and giving up). The big variance indicates it could/should be given some time to prep/investigate in order to narrow the estimate. When there are unknowns, make a wide estimate. Convey the uncertainty. If the unknowns are ridiculous, make a ridiculous estimate. Even “5-200 days” is useful because something else with less uncertainty can be chosen instead.

kelnos 4y ago
The SO question addresses this, though: after giving an estimate with a range, the developer is pressured to narrow that range, mainly by pulling in the farther-out date in the range, and then the developer is blamed when the project inevitably comes in late because of that. Maybe the solution here is "stick to your guns", but that can have negative career implications.
- alkonaut 4y ago
  That’s perfectly expected. But the key is: narrowing the estimate isn’t free. You can’t pull a different estimate out of thin air. And zero people will expect it. The developer needs to say “I can say 10-100 days right now in this meeting, but given just 1 day of investigating, I’ll narrow the estimate range by an order of magnitude”.
  - deleted 4y ago
    [deleted]
InexSquirrel 4y ago
I agree with this sentiment. I'm running through a similar situation now, where I'm somewhat adjacent to a client and a dev team. The client has a list of tasks he wants done, and he'd like banded estimates for the effort the dev team thinks it will take to complete each. The developers are obliging, but one of them complained to me privately "why doesn't he just give us 2 months of budget and we'll get through as much as we can?" - which is an interesting statement. From the developer's perspective, this is ideal. They are very good and work hard and have integrity, so I'm sure something like that would work, from their perspective. They can just 'go' and get stuff done. From the client's perspective though, it just raises a bunch of uncertainty. He wants to know what he could get out of his 2 months of development budget. If one task took all 2 months, and the others (15 in this case) didn't get done, is that OK? What if some important task wasn't that much effort? You'd potentially want to priortise that over a bigger item. Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships.

DeathArrow 4y ago

> Unfortunately this bit of illogic is so common that I know it’s a waste of time to argue, so I’ve learned how to figure out what they want the estimates to be, give them that, miss them (just like everybody else does), and then get to work on actually providing the feature. I do that and I've become exceptionally good at blaming the business persons for the outcome, making them admit their guilt in public and all that in what seems a friendly, positive and constructive manner and using business motivation and explanation. They never understood what hit them. Every programmer can do that if he or she learns a bit of psychology.

meghan_rain 4y ago
Can you elaborate?
- DeathArrow 4y ago
  I just confront business people with the results of their choices in a civil and polite manner. If some manager made a promise to a client out of his/her ass without asking us, and if the PO pressures us towards meeting an unrealistic time-frame, when that explodes I just explain in a public meeting where upper management and all stake holders take part why it was wrong to promise that, using arguments and business considerents because bussineses people don't care about tech considerents. It usually results in that person admitting in public their mistake and even saying they are sorry. I don't do that to humiliate people but to teach them to ask the team implementing the feature to estimate or to say if that feature is even reasonable or possible given current state and resources.

jfengel 4y ago

The estimates are useful even if they're wrong. Not all managers realize that, so they ask the question badly. And they never teach it to programmers. The estimates aggregate to a number more accurate than each individual. The manager cares more about the sum total than each individual one. Many can even slip without affecting the end date. This isn't so hard, if management and developers didn't treat each other as enemies. Each can get wrapped around the axle concerning each deadline, rather than the real goal of allocating resources across the entire scope.

iblaine 4y ago

It’s monumentally frustrating to be forced to give estimates too soon in the planning process. The compromise, I hope, is to end up in a place where most of the problem is known and some is unknown, and you get there by breaking down the original problem. Leave it up to the “buyer” to digest your best estimate into their planning process.

UncleMeat 4y ago

The response to "there are too many unknowns to provide any sort of estimate" shouldn't be exactly "well, we need estimates." But "okay, just do whatever" is also not a working outcome. Software is weird, yes. But other disciplines are able to provide useful planning information. Why are we unable to do that?

lazide 4y ago
Most other disciplines have this exact same problem. Construction contractors for instance, are notorious for it. The difference is, the law says if a contractor signs a contract to do something at x price, they HAVE to do so or suffer consequences. So contractors go broke/bankrupt, lose their licenses, or figure out how to bid correctly enough they can either weasel out of it if it goes sideways or they have enough wiggle room to deal with the inevitable problems. Software Engineering Consultants have the same situation. But directly employed software engineers are in a different position of course. One thing that typically makes this worse, is the implicit assumption that planning/quoting/estimating is ‘free’ work, and since it CAN make things easier to deliver, therefore we should do more and more of it as, since it’s free, it will solve the problem no?
- UncleMeat 4y ago
  Other disciplines have problems with slippage, but none of my friends who are in physical engineering fields insist that they shouldn't even have to provide estimates in the first place.
  - lazide 4y ago
    Of course not, their protected place comes with conditions like giving estimates (and being held to them). And their disciplines involve massive capital outlays which can’t be refactored in a cost effective way, or at all really. Not defending the ‘no estimate ever’ approach, it doesn’t work. They are different though.
jiggawatts 4y ago
Really, they can, can they? Even the bespoke, one-off projects with unknown unknowns? Tell me, how accurate were the estimates for the launch date of JWST? I’ll wait here while you look up how many times and how many years that “slipped”. I bet some dumbass NASA manager asked the team to schedule the launch date back in the 1990s.

tsgagnon 4y ago

Unfortunately this bit of illogic is so common that I know it’s a waste of time to argue, so I’ve learned how to figure out what they want the estimates to be, give them that, miss them (just like everybody else does), and then get to work on actually providing the feature. It gets even worse when you are in a line of work where the estimates are part of some kind of sales pipeline. Then you aren't just estimating based on effort required, but also against a likely number that the customer will ever agree to.

Buttons840 4y ago

App idea for tracking projects: Each individual developer can anonymously indicate how far along they believe a project is. For example, Developer A thinks the project is 60% complete, but Developer B thinks the project is 30% complete. Use algorithms to predict the completion date. However, I don't think this idea would be very popular because it removes the manager's ability to control the presentation and play politics.

deleted 4y ago
[deleted]

idopmstuff 4y ago

See in this case the manager has done a bad job, but the developer has also done a bad job, both in the exact same way. The correct solution here isn't just to insist estimation is impossible and be offended that someone would ask for it - that just misunderstands how businesses work. The correct thing is for either of those parties to say, "Okay, I understand it's not estimable at the moment. What are the steps that we need to take in order to get a reasonable estimate?" A good PM will do this, but where there is a bad PM, a developer can step in and say the same thing. In your scenario, "The developer says “there are too many unknowns to provide any sort of estimate”." What the developer could say is, "There are too many unknowns to provide any sort of estimate - let me give you a few examples. <examples>. What I can do is come back to you after <amount of time> with a list of the unknowns and an explanation of the work required to evaluate them, so that we have enough information to estimate. Once you have that list, then you can decide if we want to proceed with the work to understand those unknowns." I totally understand why developers get frustrated when they're asked to give estimates for things that can't reasonably be estimated with the current information available. But the flip side is it's also very reasonable for PMs to get frustrated and ignore developers who insist that estimation is an impossibility, because that's virtually never true - maybe it's impossible to do now, but there is a path to make it possible. If you work proactively to expose that path to the PM, it'll generally result in everyone being happier.

myshpa 4y ago
> There are too many unknowns to provide any sort of estimate - let me give you a few examples. What I can do is come back to you after amount of time with a list of the unknowns and an explanation of the work required to evaluate them, so that we have enough information to estimate Sometimes we don't know what we don't know. If we don't know what we don't know now and if we don't know what we'll find we don't know later, then we don't know how long we will need until we'll know. Uff. Sorry. If I had more time, I would have written a better comment.
- idopmstuff 4y ago
  Let's put it this way, then - either you're totally incapable of building whatever we're talking about under any circumstances, or, even if it has unknowns, there are steps you can take in the right direction to get started and move things along. You will learn things that will help you understand the problem better along the way. If it's the latter case, then a good developer can describe the immediate steps they'll take and what questions they expect to answer. Whatever the case, there is always some concrete next step you can take to which you can assign a reasonable estimate of time. That might just be that you'll spend one day perusing some documentation, and the only outcome you expect from that is that you'll develop a reasonable enough understanding of how large/complex the documentation is, such that you can come back with an estimate of how long it will take to find and carefully read all the relevant sections of the documentation. That's totally fine - if it's the sort of wildly unknown problem that you're describing, then I recognize we'll have to take steps to understand the problem. There's still never a case where it's impossible to create an immediate plan of action and understand roughly how long that will take (unless you are simply unqualified to take on the problem). I had a boss loved the phrase, "a date for a date." He just meant that if you can't give me a date for when the thing will be done, then you need to give me a date for when you can give me a date for when the thing will be done. Can't do that? Date for a date for a date. However many levels we have to go, you're not getting out of whatever meeting we're in until you can give me a date by which you'll be able to come back and give me another date.

awesome_dude 4y ago

No, hard no. In my experience good communication solves this every time. MGMT: We need an estimate ENG: I have several unknowns MGMT: We really need an estimate ENG: This is my rough estimate, but be aware that the unknowns could change this drastically MGMT: Ok, what do you need to get a firmer estimate. And so on. As a project progresses, the communication between ENG and MGMT is crucial to ensure that MGMT are aware how those unknowns are affecting the project, MGMT will decide at every juncture if the project is worthwhile to continue to invest resources into it (assuming they avoid the sunk cost fallacy)

doctor_eval 4y ago

Estimates are theatre. It’s not even theoretically possible to provide accurate estimates for anything but the most trivial project, yet here we are. As an industry we just seem incapable of coming up with any other way of negotiating and running projects.

Fire-Dragon-DoL 4y ago

You can say this, but when a plumber or an electrician comes home, they are always expected to provide quotes and duration of work

mewpmewp2 4y ago

The fair thing to say is that there's something like 80-90% chance that this will take X time, 99% chance that it will take less than Y time. This would allow for planning, prioritising and is the most accurate communication we can achieve.

wruza 4y ago
The best thing to do is to define tradeoff ranges and set the deadline, so that developers could try an optimistic path, learn what’s wrong with it halfway, and then choose a tradeoff that both seems not that bad enough and, when it fails, leaves time to rethink and use another tradeoff which is even good now, in a sense. Because that’s what we do either way. Round numbers from ass make no science to plan and prioritize upon.

antman 4y ago

A general framework is that on each decision, including architecture, cost, time one at least adds the following: 1. Assumptions (including soft such as who will actually do it, resources are not equally relevant or productive) 2. Constraints (as agreed by stakeholders) 3. Risks 4. Clear scope 3. Alternatives and why they were not preferred Business should be aware and own the uncertainties, or else the system gets biased towards sales people offering vaporware.