14 ms·

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 m

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.
- gghffguhvc 4y ago
  Agreed. Having human dependencies who have competing priorities or unknown competencies on the critical path is such a big risk on timelines. In some cases I’ve got agreements up front that if the dependencies aren’t done or being worked on by particular dates my team gets access to the codebase or systems and can take over. That type of consequence/potential embarrassment can set up potential adversarial positions but it has helped a few times.
- hgsgm 4y ago
  You've identified the problem but missed the solution: don't bet your business on a dependency that doesn't exist yet. Be useful enough to work on a different project, or take a furlough until you are needed.
  - a_t48 4y ago
    Sure! We agree - though it would be nice to know if I can come back to it tomorrow or in six months.
throw__away7391 4y ago
And yet at most companies an army of "facilitators" exist, with access to extensive tracking metrics and tools. They should be able to at a minimum ask the right questions (i.e. not "how long will x take") to create and maintain the estimates.
pulvinar 4y ago
I don't think there's any question that people always want this estimate. The problem with most software is that there really isn't one, since it's usually an open-ended search for a solution. Also, a job on his home is exactly what it should not be compared with, since that's the sort of repeatable job that can be estimated.
- davidivadavid 4y ago
  That begs for supporting evidence. I doubt most software is open-ended research.
  - commandlinefan 4y ago
    > I doubt most software is open-ended research. No, just all software that provides any sort of tangible benefit to anybody. I’m sure you could estimate fairly accurately how long it would take to implement quicksort - but nobody’s going to ask you that.
  - pulvinar 4y ago
    Frederick Brooks' "Mythical Man-Month" book is the classic answer. For my own evidence I base it on 50 years experience. I just wrote a piece of code that I had all working, but then I discovered a new method (requiring rewriting it all) that greatly improved it in every respect. So was I 90% done before that? Coding is just a very non-linear and never-ending process.
    - kube-system 4y ago
      You were 100% done. And then you discovered an opportunity for new work. I know many developers enjoy the art of software development and want to continually improve it, but that isn’t always the task you are being paid to do.
      - remkop22 4y ago
        This exactly. There are many ways to remodel a bathroom. Some more optimal than others. Now imagine your plumber tells you he discovered a better layout for the plumbing just after finishing his work, then he enthusiastically asks if he could tear everything out and start over (and pay him for it).
stemlord 4y ago
Basically the author is lamenting that estimations are NEVER accurate enough. I've not known a dev who made accurate enough estimations to avoid a crunch. It does seem like the responders have a little bit too much sunk cost in the whole famously fraught agile thing to understand critique of it unbiased. It's fine in theory but does have flaws.
- AnimalMuppet 4y ago
  One flavor of agile (XP) says that estimates longer than 3 weeks diverge from reality too much. If you want to be able to estimate accurately, you must break it down until every task's estimate is less than 3 weeks. That doesn't give you an accurate estimate, but it does usually give you a less inaccurate one.
- ghaff 4y ago
  I'd probably argue that any accurate estimate almost has to have some slack built in. For any task of any complexity, especially one requiring coordination, things rarely go more easily and quickly than you expect. Far more likely, you run into problems or you really need to talk to a person about something and they're on vacation.
- WastingMyTime89 4y ago
  > I've not known a dev who made accurate enough estimations to avoid a crunch. And yet after three years at my first job, I could easily do a quick breakdown on a project, assign a three level complexity to each step (easy, medium, hard), put an amount of days corresponding to the selected complexity (to be reviewed after each project), add 25% for unforeseen events and contingency and my estimates were accurate enough most of the time. It is not difficult to properly do rough estimates. Most developers just refuse to invest the time necessary to do it properly and sadly for some as the answers here already illustrate I do believe it’s because they think of themselves as special snowflake rather than team player.
bbbbzzz1 4y ago
> If developers have to be the ones carefully calculating estimates and managing expectations then there's really no purpose to middle-management. Op is not saying that having estimates is useless, but rather it should be a management task rather than a developers burden. To me, that sounds even worse, but I do think devs are expected to do wider and wider tasks across the business. Their post reeks of resentment against management and PMs and I don't blame them. Especially in my experience, I have worked with PMs that I have no idea what they do as devs need to step in to do all project management related tasks themselves
- colinmorelli 4y ago
  Just to be clear, most of the time “management” comes to developers with a proposed timeline, there’s significantly more complaints than if the engineers are asked to estimate. Asking the builders to estimate the time they need is a good sign of high trust in that team. It’s healthy. We should want more of it. The business’ side of the commitment is to understand that it is an estimate and should be treated accordingly.
  - Retric 4y ago
    I don’t mind someone giving deadlines because I can then scope quality to fit those expectations.
    - iamcasen 4y ago
      Exactly this! Most managers are not expecting the air-tight rocket science that most software devs seem to insist is absolutely necessary. I was tasked with creating an entire email campaign system (like mailchimp). But I had only 3 weeks to do it. I made the deadline no problem, but the system had numerous obvious issues. My boss didn't care, because the task was not about delivering a perfect email system. The task was getting something useful in the hands of customers rapidly. If a feature starts getting heavy use, then more investment is justified.
    - jxidjhdhdhdhfhf 4y ago
vlunkr 4y ago
That sounds great and all, except that estimates are usually wrong. It’s a real problem when estimates are treated as deadlines, which is exactly what you’re describing.
deleted 4y ago
[deleted]
BillyTheKing 4y ago
this assumes that there’s a buyer of software, and that the buyer decides which software to build. In those cases estimates might make sense But in many other instances (product/engineering led companies, start-ups) software isn’t built for a buyer, it’s build for a user - and a user doesn’t care if it took 5 days or 15 weeks to build their favourite feature. What they care about is that you build features those users actually want. In those cases estimates form part of a whole basket of mechanisms and rules designed to ‘shield’ developers from users and vice versa, which imo is among the biggest mistakes one can make in such software companies.
- justeleblanc 4y ago
  A user doesn't care. Your boss cares if the competing company built the feature in half the time as you and snatches half your user base.
adamredwoods 4y ago
Give them a break, they're venting but they're raising valid problems within the workplace (don't go by the headline alone). I've personally been in this spot and had to seek outside help to identify issues within my workplace! They key is negotiations, and both parties being able to balance a moving target of requirements and scope. Large software development is not a determinable thing as much as we would like. Perhaps ChatGPT will solve this? >> 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? Even this is not always accurately determinable! If you've had work done in your home, or heard anecdotes from others, you would realize this.
commandlinefan 4y ago
> 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.
Thaxll 4y ago
It's not just about external factors, you can't let you dev go dev for an infinite amount of time. Task should be done at some point and you should roughly know how long it should take.
deleted 4y ago
[deleted]
osigurdson 4y ago
If the expected ROI on a particular project is so razor thin that accurate estimates are needed, don’t even start. Be sure to do your due diligence and aim for at least 10X (ideally > 100X). If this is provably true, then accurate estimates will not be needed. If this cannot be concluded, simply live with the limitations of off-the-shelf offerings.
- analog31 4y ago
  I think this is a big part of it. For every manager with an unrealistic schedule demand, there's a manager above them with an unrealistic ROI demand. The projects with accurate schedules and accurate ROI's don't get approved.
- pdhborges 4y ago
  Tom DeMarco expressed the same exact point: > https://www.computer.org/csdl/magazine/so/2011/06/mso2011060104/13rRUwI5Uj1 https://www.computer.org/csdl/magazine/so/2011/06/mso2011060...
fnordpiglet 4y ago
And giving people a precise and inaccurate estimate makes this better? A capped time and budget won’t make it take that amount of time or money. It takes what it takes. The complexity and amount of randomness in these processes mean any expectation has wildly large variance, with a long tail in the wrong direction. If you want home builder like estimates, build a home, not software.
dsizzle 4y ago
> 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? The author made the claim that software engineering is fundamentally different from carpentry ("Almost everything a developer writes is unique, they have never built that particular thing before. We are not cabinet makers...") But does that hold up? Many software projects do in fact have a similar analogue, and each house is unique and carpentry projects will thus run into unexpected snags.
- gabereiser 4y ago
  He/she hasn’t been around enough to see these patterns yet. The amount of times I’ve had to implement security, rbac, rest crud, modeling, service integrations, etc are too many to count. I rely on packages that help reduce the boilerplate and because I’ve done that so many times, I can give you an estimate on roughly how long it will take. The fact that the OP doesn’t see this is fact that they are too junior to be asked for estimates at all.
  - efnx 4y ago
    Or they’re very senior in a pioneering domain that doesn’t have all these packages written. It really depends on what domain you are programming in.
    - gabereiser 4y ago
      If that were the case, the business would know this and wouldn’t be asking you for estimates to return back to the client.
      - efnx 4y ago
        In my experience corps doing pioneering work don’t always act as though they are pioneering.
hk1337 4y ago
> Software development is not carpentry. I found that assumption to be ludicrous too.
DeathArrow 4y ago
> - The buyer has to make commitments externally, for instance to customers, partners, finance, marketing, his boss; Usually a business person makes some promise to the buyer or his/her boss that a certain feature will be done in X amount of time without consulting the team who does the work. The result might be overworking, resentments, stuff not being done in time and technical debt.
- justeleblanc 4y ago
  You can't have it both ways. Either you ask the developers for an estimate and you get ridiculed because how can developers possibly have any clue how long it's going to take them something? A day, a month, a year, who knows how much time this CRUD service will take! Or you don't consult with your developers, but then you've made an unrealistic promise with a number pulled out of your pants and you're the cause of all the suffering in your team.
  - DeathArrow 4y ago
    No. Realistic is talking to your team exposing all the knowns and unknowns, refine the feature as realistically possible, while keeping the client in the loop, and once the feature is decently refined you ask the team for an estimation, take the higher limit and add a buffer for things that are not development related. In the best case the feature will be done earlier, in the worst case you won't look like an idiot which promised things and didn't deliver and you won't compromise your relationship with the team. Compromising relationships with either clients or tech teams aren't good for your career. More simply put, try to be as honest as possible. Not over promise, not under deliver. One of my former girlfriends went to a business school and worked in banking. She thought people in IT have better salaries and she thinked tech people are a bunch of idiots and it's easy to push them to do things and extract a fat paycheck. So she did some courses on IT management and applied to lots of product owner and product manager role. After tens of interviews she hadn't had one success. To add insult to the injury, I showed her I make more money as a team lead than the product owner. Of course, the reverse is true and I've seen product owners being genuinely useful and having lots of business knowledge, some even programing knowledge. Some people are just after the money, no matter what role they occupy in an IT company. And they tend to be the least useful persons who are blocking others to reach full potential.
joe_the_user 4y ago
The problem is the writer of the question is conflating two things. Their quote: "A. Give a very wide estimate with a lot of padding. B. Get pressured to be more accurate and to bring the estimate down..." The real problem seems to be getting pressured to reduce their estimate, they only summarize things as the problem being that they're asked for an estimate at all.
- lazyasciiart 4y ago
  I’ve known people whose version of A was “between a year and five years” for something where five years was clearly a ludicrous amount of time to spend and a year would be stunning. In those cases, the problem is that they aren’t really bothering to give an estimate at first, so the pressure to give one continues.
yarg 4y ago
- The manager needs someone else to blame.
peteradio 4y ago
I wouldn't hire someone to do a job in my home that they've never completed before.
dzhiurgis 4y ago
Every project I ever worked on was more like “okay we already building it” and estimate was the last step after spending hours of discussions. My manager was typically had enough clue to estimate themselves too.
alwaysbeconsing 4y ago
> 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? Huh? Every major contract job on my house and my friends' houses that I have heard of has taken longer than originally "planned". More often than not unexpected expenses come up along the way. The same is true for commercial construction/remodeling. That's just how these things work; pretending otherwise is going to be a huge source of friction.
AtlasBarfed 4y ago
And your response naively suggests the business people are being above board. The real reason is to provide a scapegoat for the 50% of times it fails (ratio from Mythical Man Month) "But but but but OUR organization isn't like that!" Sure.
heisenbit 4y ago
Absolute estimate done right force scoping decisions which can be very valuable. Relative estimates like planning poker can reveal hidden assumptions. Commercial estimates can reveal risk appetite, desperation and more. All estimates create insights but imho. it is best to burn the paper with the number after writing.
tdrgabi 4y ago
I do wonder if developers would accept the same from people they "employ" to do a task. I imagine sometimes I renovate my kitchen, an expensive task, within my budget but with not a lot of leeway, I can't renovate the kitchen twice for example. If the workers say they don't know how long it will cost and they won't provide an estimate to when ... I would not be happy. Even creatives, writers, musicians, graphic artists have deadlines and must estimate their work. But we feel that our work is special and should not be asked to give an estimate.
HardlyCurious 4y ago
I'm not sure why you feel the need to falsely frame the point as a request for a blank check. I get all the reasons you provided, but at the end of the day an honest discussion needs to ask is estimating tasks effective. Do developers get more done or less done when estimating tasks vs not estimating tasks? The only claim estimates would increase productivity is the extent they are deadlines. But I think you will see that when developers take meeting their estimates seriously their estimates tend to get more conservative. And then there can be a desire to not over deliver on the estimates to lend those estimates legitimacy. Without estimates, you still have a performance metric to use, individual velocity. If one developer isn't getting stuff done as fast as others, you don't need estimates to know they aren't performing as you would like. Are estimates reliable? This of course varies greatly by the project and the team but I my experience estimates are typically no more precise than 50% of their length. So a 6 month project probably shouldnt take longer than 9 months. Your mileage may vary, but is there a way to crudely estimate a project without asking for estimates? I would say probably. Why not just measure the teams velocity and project it? I would argue estimates were a first guess at a way to run a development team which has survived mostly because of a refusal to consider the first guess might not have been the best guess.
tyingq 4y ago
This is also hard to agree with: "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." Some software development fits this description. Quite a lot of it does not.
ozmaverick72 4y ago
The difference between the buyer of a house and the buyer of software is that the house purchaser is clearly and succinctly able to communicate his / her desires and expectations. Where as the purchaser of software is making some vague request for functionality with poorly defined boundaries and requirements. There is little meaningful comparison of the two scenarios that can be made.
cauliflower99 4y ago
Hear, hear. Anyone who has worked in a quasi-management or leadership position before will understand the need for an answer to the question: "We don't have unlimited finances. Tell me how much money I need to put towards this." Having said that, most developers refuse to respond intelligently to these questions. The answer to almost all of these question should be something like "I think delivering this goal might take X resources, but here's the smaller goals we're going to deliver along the way to the big goal so that we can reposition when we go off-track." Instead, developers say "Well we have to make sure that EVERYTHING can fit into this timebox, and our manager is going to treat this estimate as a deadline, so estimates suck!" This question is supposed to be a conversation starter. Don't shoot the manager for doing their job. And even when the manager does a poor job and treats your estimates as deadlines, call it out! It's up to the developers to put up a bit of a fight and make more intelligent decisions too. I've only met a handful of developers who are able to have a conversation like this. It's what the 'Agile' movement was attempting to fix. But it turns out conversations skills are tricky things to impart.

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.

gghffguhvc 4y ago
Agreed. Having human dependencies who have competing priorities or unknown competencies on the critical path is such a big risk on timelines. In some cases I’ve got agreements up front that if the dependencies aren’t done or being worked on by particular dates my team gets access to the codebase or systems and can take over. That type of consequence/potential embarrassment can set up potential adversarial positions but it has helped a few times.
hgsgm 4y ago
You've identified the problem but missed the solution: don't bet your business on a dependency that doesn't exist yet. Be useful enough to work on a different project, or take a furlough until you are needed.
- a_t48 4y ago
  Sure! We agree - though it would be nice to know if I can come back to it tomorrow or in six months.

throw__away7391 4y ago

And yet at most companies an army of "facilitators" exist, with access to extensive tracking metrics and tools. They should be able to at a minimum ask the right questions (i.e. not "how long will x take") to create and maintain the estimates.

pulvinar 4y ago

I don't think there's any question that people always want this estimate. The problem with most software is that there really isn't one, since it's usually an open-ended search for a solution. Also, a job on his home is exactly what it should not be compared with, since that's the sort of repeatable job that can be estimated.

davidivadavid 4y ago
That begs for supporting evidence. I doubt most software is open-ended research.
- commandlinefan 4y ago
  > I doubt most software is open-ended research. No, just all software that provides any sort of tangible benefit to anybody. I’m sure you could estimate fairly accurately how long it would take to implement quicksort - but nobody’s going to ask you that.
- pulvinar 4y ago
  Frederick Brooks' "Mythical Man-Month" book is the classic answer. For my own evidence I base it on 50 years experience. I just wrote a piece of code that I had all working, but then I discovered a new method (requiring rewriting it all) that greatly improved it in every respect. So was I 90% done before that? Coding is just a very non-linear and never-ending process.
  - kube-system 4y ago
    You were 100% done. And then you discovered an opportunity for new work. I know many developers enjoy the art of software development and want to continually improve it, but that isn’t always the task you are being paid to do.
    - remkop22 4y ago
      This exactly. There are many ways to remodel a bathroom. Some more optimal than others. Now imagine your plumber tells you he discovered a better layout for the plumbing just after finishing his work, then he enthusiastically asks if he could tear everything out and start over (and pay him for it).

stemlord 4y ago

Basically the author is lamenting that estimations are NEVER accurate enough. I've not known a dev who made accurate enough estimations to avoid a crunch. It does seem like the responders have a little bit too much sunk cost in the whole famously fraught agile thing to understand critique of it unbiased. It's fine in theory but does have flaws.

AnimalMuppet 4y ago
One flavor of agile (XP) says that estimates longer than 3 weeks diverge from reality too much. If you want to be able to estimate accurately, you must break it down until every task's estimate is less than 3 weeks. That doesn't give you an accurate estimate, but it does usually give you a less inaccurate one.
ghaff 4y ago
I'd probably argue that any accurate estimate almost has to have some slack built in. For any task of any complexity, especially one requiring coordination, things rarely go more easily and quickly than you expect. Far more likely, you run into problems or you really need to talk to a person about something and they're on vacation.
WastingMyTime89 4y ago
> I've not known a dev who made accurate enough estimations to avoid a crunch. And yet after three years at my first job, I could easily do a quick breakdown on a project, assign a three level complexity to each step (easy, medium, hard), put an amount of days corresponding to the selected complexity (to be reviewed after each project), add 25% for unforeseen events and contingency and my estimates were accurate enough most of the time. It is not difficult to properly do rough estimates. Most developers just refuse to invest the time necessary to do it properly and sadly for some as the answers here already illustrate I do believe it’s because they think of themselves as special snowflake rather than team player.

bbbbzzz1 4y ago

> If developers have to be the ones carefully calculating estimates and managing expectations then there's really no purpose to middle-management. Op is not saying that having estimates is useless, but rather it should be a management task rather than a developers burden. To me, that sounds even worse, but I do think devs are expected to do wider and wider tasks across the business. Their post reeks of resentment against management and PMs and I don't blame them. Especially in my experience, I have worked with PMs that I have no idea what they do as devs need to step in to do all project management related tasks themselves

colinmorelli 4y ago
Just to be clear, most of the time “management” comes to developers with a proposed timeline, there’s significantly more complaints than if the engineers are asked to estimate. Asking the builders to estimate the time they need is a good sign of high trust in that team. It’s healthy. We should want more of it. The business’ side of the commitment is to understand that it is an estimate and should be treated accordingly.
- Retric 4y ago
  I don’t mind someone giving deadlines because I can then scope quality to fit those expectations.
  - iamcasen 4y ago
    Exactly this! Most managers are not expecting the air-tight rocket science that most software devs seem to insist is absolutely necessary. I was tasked with creating an entire email campaign system (like mailchimp). But I had only 3 weeks to do it. I made the deadline no problem, but the system had numerous obvious issues. My boss didn't care, because the task was not about delivering a perfect email system. The task was getting something useful in the hands of customers rapidly. If a feature starts getting heavy use, then more investment is justified.
  - jxidjhdhdhdhfhf 4y ago

vlunkr 4y ago

That sounds great and all, except that estimates are usually wrong. It’s a real problem when estimates are treated as deadlines, which is exactly what you’re describing.

deleted 4y ago

[deleted]

BillyTheKing 4y ago

this assumes that there’s a buyer of software, and that the buyer decides which software to build. In those cases estimates might make sense But in many other instances (product/engineering led companies, start-ups) software isn’t built for a buyer, it’s build for a user - and a user doesn’t care if it took 5 days or 15 weeks to build their favourite feature. What they care about is that you build features those users actually want. In those cases estimates form part of a whole basket of mechanisms and rules designed to ‘shield’ developers from users and vice versa, which imo is among the biggest mistakes one can make in such software companies.

justeleblanc 4y ago
A user doesn't care. Your boss cares if the competing company built the feature in half the time as you and snatches half your user base.

adamredwoods 4y ago

Give them a break, they're venting but they're raising valid problems within the workplace (don't go by the headline alone). I've personally been in this spot and had to seek outside help to identify issues within my workplace! They key is negotiations, and both parties being able to balance a moving target of requirements and scope. Large software development is not a determinable thing as much as we would like. Perhaps ChatGPT will solve this? >> 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? Even this is not always accurately determinable! If you've had work done in your home, or heard anecdotes from others, you would realize this.

commandlinefan 4y ago

> 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.

Thaxll 4y ago

It's not just about external factors, you can't let you dev go dev for an infinite amount of time. Task should be done at some point and you should roughly know how long it should take.

deleted 4y ago

[deleted]

osigurdson 4y ago

If the expected ROI on a particular project is so razor thin that accurate estimates are needed, don’t even start. Be sure to do your due diligence and aim for at least 10X (ideally > 100X). If this is provably true, then accurate estimates will not be needed. If this cannot be concluded, simply live with the limitations of off-the-shelf offerings.

analog31 4y ago
I think this is a big part of it. For every manager with an unrealistic schedule demand, there's a manager above them with an unrealistic ROI demand. The projects with accurate schedules and accurate ROI's don't get approved.
pdhborges 4y ago
Tom DeMarco expressed the same exact point: > https://www.computer.org/csdl/magazine/so/2011/06/mso2011060104/13rRUwI5Uj1 https://www.computer.org/csdl/magazine/so/2011/06/mso2011060...

fnordpiglet 4y ago

And giving people a precise and inaccurate estimate makes this better? A capped time and budget won’t make it take that amount of time or money. It takes what it takes. The complexity and amount of randomness in these processes mean any expectation has wildly large variance, with a long tail in the wrong direction. If you want home builder like estimates, build a home, not software.

dsizzle 4y ago

> 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? The author made the claim that software engineering is fundamentally different from carpentry ("Almost everything a developer writes is unique, they have never built that particular thing before. We are not cabinet makers...") But does that hold up? Many software projects do in fact have a similar analogue, and each house is unique and carpentry projects will thus run into unexpected snags.

gabereiser 4y ago
He/she hasn’t been around enough to see these patterns yet. The amount of times I’ve had to implement security, rbac, rest crud, modeling, service integrations, etc are too many to count. I rely on packages that help reduce the boilerplate and because I’ve done that so many times, I can give you an estimate on roughly how long it will take. The fact that the OP doesn’t see this is fact that they are too junior to be asked for estimates at all.
- efnx 4y ago
  Or they’re very senior in a pioneering domain that doesn’t have all these packages written. It really depends on what domain you are programming in.
  - gabereiser 4y ago
    If that were the case, the business would know this and wouldn’t be asking you for estimates to return back to the client.
    - efnx 4y ago
      In my experience corps doing pioneering work don’t always act as though they are pioneering.

hk1337 4y ago

> Software development is not carpentry. I found that assumption to be ludicrous too.

DeathArrow 4y ago

> - The buyer has to make commitments externally, for instance to customers, partners, finance, marketing, his boss; Usually a business person makes some promise to the buyer or his/her boss that a certain feature will be done in X amount of time without consulting the team who does the work. The result might be overworking, resentments, stuff not being done in time and technical debt.

justeleblanc 4y ago
You can't have it both ways. Either you ask the developers for an estimate and you get ridiculed because how can developers possibly have any clue how long it's going to take them something? A day, a month, a year, who knows how much time this CRUD service will take! Or you don't consult with your developers, but then you've made an unrealistic promise with a number pulled out of your pants and you're the cause of all the suffering in your team.
- DeathArrow 4y ago
  No. Realistic is talking to your team exposing all the knowns and unknowns, refine the feature as realistically possible, while keeping the client in the loop, and once the feature is decently refined you ask the team for an estimation, take the higher limit and add a buffer for things that are not development related. In the best case the feature will be done earlier, in the worst case you won't look like an idiot which promised things and didn't deliver and you won't compromise your relationship with the team. Compromising relationships with either clients or tech teams aren't good for your career. More simply put, try to be as honest as possible. Not over promise, not under deliver. One of my former girlfriends went to a business school and worked in banking. She thought people in IT have better salaries and she thinked tech people are a bunch of idiots and it's easy to push them to do things and extract a fat paycheck. So she did some courses on IT management and applied to lots of product owner and product manager role. After tens of interviews she hadn't had one success. To add insult to the injury, I showed her I make more money as a team lead than the product owner. Of course, the reverse is true and I've seen product owners being genuinely useful and having lots of business knowledge, some even programing knowledge. Some people are just after the money, no matter what role they occupy in an IT company. And they tend to be the least useful persons who are blocking others to reach full potential.

joe_the_user 4y ago

The problem is the writer of the question is conflating two things. Their quote: "A. Give a very wide estimate with a lot of padding. B. Get pressured to be more accurate and to bring the estimate down..." The real problem seems to be getting pressured to reduce their estimate, they only summarize things as the problem being that they're asked for an estimate at all.

lazyasciiart 4y ago
I’ve known people whose version of A was “between a year and five years” for something where five years was clearly a ludicrous amount of time to spend and a year would be stunning. In those cases, the problem is that they aren’t really bothering to give an estimate at first, so the pressure to give one continues.

yarg 4y ago

- The manager needs someone else to blame.

peteradio 4y ago

I wouldn't hire someone to do a job in my home that they've never completed before.

dzhiurgis 4y ago

Every project I ever worked on was more like “okay we already building it” and estimate was the last step after spending hours of discussions. My manager was typically had enough clue to estimate themselves too.

alwaysbeconsing 4y ago

> 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? Huh? Every major contract job on my house and my friends' houses that I have heard of has taken longer than originally "planned". More often than not unexpected expenses come up along the way. The same is true for commercial construction/remodeling. That's just how these things work; pretending otherwise is going to be a huge source of friction.

AtlasBarfed 4y ago

And your response naively suggests the business people are being above board. The real reason is to provide a scapegoat for the 50% of times it fails (ratio from Mythical Man Month) "But but but but OUR organization isn't like that!" Sure.

heisenbit 4y ago

Absolute estimate done right force scoping decisions which can be very valuable. Relative estimates like planning poker can reveal hidden assumptions. Commercial estimates can reveal risk appetite, desperation and more. All estimates create insights but imho. it is best to burn the paper with the number after writing.

tdrgabi 4y ago

I do wonder if developers would accept the same from people they "employ" to do a task. I imagine sometimes I renovate my kitchen, an expensive task, within my budget but with not a lot of leeway, I can't renovate the kitchen twice for example. If the workers say they don't know how long it will cost and they won't provide an estimate to when ... I would not be happy. Even creatives, writers, musicians, graphic artists have deadlines and must estimate their work. But we feel that our work is special and should not be asked to give an estimate.

HardlyCurious 4y ago

I'm not sure why you feel the need to falsely frame the point as a request for a blank check. I get all the reasons you provided, but at the end of the day an honest discussion needs to ask is estimating tasks effective. Do developers get more done or less done when estimating tasks vs not estimating tasks? The only claim estimates would increase productivity is the extent they are deadlines. But I think you will see that when developers take meeting their estimates seriously their estimates tend to get more conservative. And then there can be a desire to not over deliver on the estimates to lend those estimates legitimacy. Without estimates, you still have a performance metric to use, individual velocity. If one developer isn't getting stuff done as fast as others, you don't need estimates to know they aren't performing as you would like. Are estimates reliable? This of course varies greatly by the project and the team but I my experience estimates are typically no more precise than 50% of their length. So a 6 month project probably shouldnt take longer than 9 months. Your mileage may vary, but is there a way to crudely estimate a project without asking for estimates? I would say probably. Why not just measure the teams velocity and project it? I would argue estimates were a first guess at a way to run a development team which has survived mostly because of a refusal to consider the first guess might not have been the best guess.

tyingq 4y ago

This is also hard to agree with: "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." Some software development fits this description. Quite a lot of it does not.

ozmaverick72 4y ago

The difference between the buyer of a house and the buyer of software is that the house purchaser is clearly and succinctly able to communicate his / her desires and expectations. Where as the purchaser of software is making some vague request for functionality with poorly defined boundaries and requirements. There is little meaningful comparison of the two scenarios that can be made.

cauliflower99 4y ago

Hear, hear. Anyone who has worked in a quasi-management or leadership position before will understand the need for an answer to the question: "We don't have unlimited finances. Tell me how much money I need to put towards this." Having said that, most developers refuse to respond intelligently to these questions. The answer to almost all of these question should be something like "I think delivering this goal might take X resources, but here's the smaller goals we're going to deliver along the way to the big goal so that we can reposition when we go off-track." Instead, developers say "Well we have to make sure that EVERYTHING can fit into this timebox, and our manager is going to treat this estimate as a deadline, so estimates suck!" This question is supposed to be a conversation starter. Don't shoot the manager for doing their job. And even when the manager does a poor job and treats your estimates as deadlines, call it out! It's up to the developers to put up a bit of a fight and make more intelligent decisions too. I've only met a handful of developers who are able to have a conversation like this. It's what the 'Agile' movement was attempting to fix. But it turns out conversations skills are tricky things to impart.