15 ms·

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

> 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 3y 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 3y ago
  I don’t mind someone giving deadlines because I can then scope quality to fit those expectations.
  - jxidjhdhdhdhfhf 3y ago
    Lol exactly. "Maintenance" can then be funded and estimated separately.
  - iamcasen 3y 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.
- revelio 3y ago
  >> it is an estimate and should be treated accordingly. That's where it all breaks down. What does "treated accordingly" mean? In reality it means the estimates can't be used for anything because they are always unreliable. There is no such thing as a reliable software estimate, ever, unless what you're doing is so repetitive that you're about to be replaced by AI. But that's not why people ask. Instead, half the time you give an estimate it gets immediately turned into a deadline, even if you were promised it wouldn't. The top comment on this thread is naive. The reason devs hate giving estimates or point blank refuse is because it is meaningless, that's not how the software business works. Analogies to plumbers and builders just reinforce the naivety. Guess what, blue collar work is only predictable for as long as it's highly repetitive which being physical in nature, it often is. The moment what you're asking for is "build me an underground railway using the latest technology" it turns out construction estimates are worthless too (see: Crossrail). One reason tech firms crush their competition so reliably is they don't have an estimates-deadline culture, because they're run from the top by programmers who understand intuitively why they're pointless. Instead developers are incentivized by equity, bonuses etc to do the job as fast as possible.
  - colinmorelli 3y ago
    Estimates are about relative comparison, not specific accuracy. If you tell me one item will take a day and another will take 3 months, you can be wrong by several multiples and the information is still useful. It’s less that I now have a specific endpoint, but rather I have a target (or multiple targets) at which I can decide if we’re on track and, if not, how I may want to change previously made prioritization choices. If you tell me a day, then 5 days later if it’s still not done I may not rip you for being wrong but I may decide it’s time to pull the plug on that initiative since it no longer meets the criteria under which we agreed to do it. I’m all ears for another proposal, but “just keep building stuff with no regard for how long any of it takes” is not much of a strategy and doesn’t reflect the way that decisions have to get made in the real world with limited resources.
    - revelio 3y ago
      Estimates for relative comparisons are more justifiable but rarely used, in my experience. And you can't bend on that stuff. The moment you say (to non developers), OK, I'll estimate X for task 1 and Y for task 2 they think, ah ha, if you can do estimates for this you can do estimates for all tasks. Also and I cannot stress this enough, if you can make any estimates at all you're playing on easy mode. If the stuff you're programming isn't entirely rote boilerplate then you cannot estimate anything, ever, because your error rate will be measured in orders of magnitude not multiples. Classic scenario: "how long will task X take?" ... "hmm well there's an open source library that claims to do X here, looks pretty easy to use, so maybe two days?". Some time later: "why is X taking 2 months and not 2 days?" ... "it turned out the library has some non obvious architectural limits we can't fix and which kill performance for our use case, so we have to write our own from scratch". That sort of thing - you thought you could rely on another component and then you can't - can happen at any time, to anyone, and renders all estimates based on the assumed viability of that component meaningless. But you're always building on third party work. If you have absolute confidence in all your dependencies it, again, means you are doing repetitive work that isn't much different from your last task. Such works exists, I guess a lot of frontend dev falls into that category, but it's also highly susceptible to being automated away by better frameworks or AI. >> it doesn’t reflect the way that decisions have to get made in the real world with limited resources. My experience was the opposite actually, the big successful companies do exactly that. They may cancel projects if they seem to be no hopers, but they don't try and estimate up front how much a project will take because they don't think in terms of projects at all. If something is important, it gets staffed until it either stops being important or the team is beaten, at which point it gets unstaffed. If progress isn't fast enough they add more headcount. Everything is thought of in terms of relative resource flows, not timed Gantt charts.
hgsgm 3y ago
If you've worked in the industry long enough you work with a PM who will ignore everything you say and ask for a delivery date, and then ignore everything you say until you give the date that the management or client wants. What they won't do is give you the resources and support you need to hit the date.
eapressoandcats 3y ago
One thing I find frustrating is that non-engineering people in tech companies don’t get held to as high standards of productivity because it can be harder for especially engineering founders to evaluate whether they are doing a good job. This can lead to people thinking those roles are “worthless” and then Continuing to have low standards for those roles. The best combo project/product manager I had didn’t have either official title, but we were on an internal team and somehow she always managed to make sure people around the company knew what we were doing and delivering, pester people so that no tasks were dropped, etc. Interestingly, she did most of this by putting tickets for projects into Google docs, and otherwise didn’t buy into any of the standard project management dogma. She had an ear/nose for who might want to use our stuff and was relentless at getting us on internal presentations of any teams/groups that would be interested.
justeleblanc 3y ago
> Op is not saying that having estimates is useless, but rather it should be a management task rather than a developers burden. Count how many people are also complaining about their managers giving timelines to clients. Damned if you do, damned if you don't.

colinmorelli 3y 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 3y ago
I don’t mind someone giving deadlines because I can then scope quality to fit those expectations.
- jxidjhdhdhdhfhf 3y ago
  Lol exactly. "Maintenance" can then be funded and estimated separately.
- iamcasen 3y 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.
revelio 3y ago
>> it is an estimate and should be treated accordingly. That's where it all breaks down. What does "treated accordingly" mean? In reality it means the estimates can't be used for anything because they are always unreliable. There is no such thing as a reliable software estimate, ever, unless what you're doing is so repetitive that you're about to be replaced by AI. But that's not why people ask. Instead, half the time you give an estimate it gets immediately turned into a deadline, even if you were promised it wouldn't. The top comment on this thread is naive. The reason devs hate giving estimates or point blank refuse is because it is meaningless, that's not how the software business works. Analogies to plumbers and builders just reinforce the naivety. Guess what, blue collar work is only predictable for as long as it's highly repetitive which being physical in nature, it often is. The moment what you're asking for is "build me an underground railway using the latest technology" it turns out construction estimates are worthless too (see: Crossrail). One reason tech firms crush their competition so reliably is they don't have an estimates-deadline culture, because they're run from the top by programmers who understand intuitively why they're pointless. Instead developers are incentivized by equity, bonuses etc to do the job as fast as possible.
- colinmorelli 3y ago
  Estimates are about relative comparison, not specific accuracy. If you tell me one item will take a day and another will take 3 months, you can be wrong by several multiples and the information is still useful. It’s less that I now have a specific endpoint, but rather I have a target (or multiple targets) at which I can decide if we’re on track and, if not, how I may want to change previously made prioritization choices. If you tell me a day, then 5 days later if it’s still not done I may not rip you for being wrong but I may decide it’s time to pull the plug on that initiative since it no longer meets the criteria under which we agreed to do it. I’m all ears for another proposal, but “just keep building stuff with no regard for how long any of it takes” is not much of a strategy and doesn’t reflect the way that decisions have to get made in the real world with limited resources.
  - revelio 3y ago
    Estimates for relative comparisons are more justifiable but rarely used, in my experience. And you can't bend on that stuff. The moment you say (to non developers), OK, I'll estimate X for task 1 and Y for task 2 they think, ah ha, if you can do estimates for this you can do estimates for all tasks. Also and I cannot stress this enough, if you can make any estimates at all you're playing on easy mode. If the stuff you're programming isn't entirely rote boilerplate then you cannot estimate anything, ever, because your error rate will be measured in orders of magnitude not multiples. Classic scenario: "how long will task X take?" ... "hmm well there's an open source library that claims to do X here, looks pretty easy to use, so maybe two days?". Some time later: "why is X taking 2 months and not 2 days?" ... "it turned out the library has some non obvious architectural limits we can't fix and which kill performance for our use case, so we have to write our own from scratch". That sort of thing - you thought you could rely on another component and then you can't - can happen at any time, to anyone, and renders all estimates based on the assumed viability of that component meaningless. But you're always building on third party work. If you have absolute confidence in all your dependencies it, again, means you are doing repetitive work that isn't much different from your last task. Such works exists, I guess a lot of frontend dev falls into that category, but it's also highly susceptible to being automated away by better frameworks or AI. >> it doesn’t reflect the way that decisions have to get made in the real world with limited resources. My experience was the opposite actually, the big successful companies do exactly that. They may cancel projects if they seem to be no hopers, but they don't try and estimate up front how much a project will take because they don't think in terms of projects at all. If something is important, it gets staffed until it either stops being important or the team is beaten, at which point it gets unstaffed. If progress isn't fast enough they add more headcount. Everything is thought of in terms of relative resource flows, not timed Gantt charts.

hgsgm 3y ago

If you've worked in the industry long enough you work with a PM who will ignore everything you say and ask for a delivery date, and then ignore everything you say until you give the date that the management or client wants. What they won't do is give you the resources and support you need to hit the date.

eapressoandcats 3y ago

One thing I find frustrating is that non-engineering people in tech companies don’t get held to as high standards of productivity because it can be harder for especially engineering founders to evaluate whether they are doing a good job. This can lead to people thinking those roles are “worthless” and then Continuing to have low standards for those roles. The best combo project/product manager I had didn’t have either official title, but we were on an internal team and somehow she always managed to make sure people around the company knew what we were doing and delivering, pester people so that no tasks were dropped, etc. Interestingly, she did most of this by putting tickets for projects into Google docs, and otherwise didn’t buy into any of the standard project management dogma. She had an ear/nose for who might want to use our stuff and was relentless at getting us on internal presentations of any teams/groups that would be interested.

justeleblanc 3y ago

> Op is not saying that having estimates is useless, but rather it should be a management task rather than a developers burden. Count how many people are also complaining about their managers giving timelines to clients. Damned if you do, damned if you don't.