5 ms·

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

> 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
    You mean we're all a special case :)
- magicalhippo 4y ago
  I just say that to my boss: "this would involve using a library/tool I've not yet used, so I cannot give a good estimate until I've spent some time digging into it. Right now I don't know if it will be easy or very difficult." If he really needs an estimate he'll tell me to start digging into it right away, and I'll let him know after a bit of time how it's going. If there are still large uncertainties and my boss still wants this completed by some specific date, we might try to explore alternative solutions.
  - Scarblac 4y ago
    Yes it boils down to, if the person asking for estimates understands the problems with them, it's safe to try. With bad managers it's better not to give them as they will be abused. In the above case, I didn't get that time I would need, they wanted the estimate to include that time I would need to dig into it. But that's above my estimation powers. I didn't even know if what they asked was possible at all. They went and asked someone else who did guess some number of weeks, but the work never got priority so we still don't know.
    - magicalhippo 4y ago
      > they wanted the estimate to include that time I would need to dig into it Yeah that ain't gonna fly with me.
    - mewpmewp2 4y ago
      Did you say what you are saying here? Did you say that 1) Without knowing further best case is it takes N time, worst case M time, and if there are certain obstacles it could be completely unfeasible. 2) To get more accurate time and to understand whether it's feasible I would need O time to figure that out first, and I can give you the more accurate estimate then.
      - IIsi50MHz 4y ago
        This seems unexpectedly optimistic, to me. I'd think: best case = it's already done; worst case = it's impossible, but we don't know that until we've spent too much time and money on it; the "certain obstacles" are almost always uncertain or completely unknown; and the "O time to figure out [how much time it will take] is also unknowable until the "figuring" is already complete. Now, if this were manufacturing with well-known processes, then I feel I could use your formula.
- lutorm 4y ago
  estimates, which turn into deadlines Well, that's the problem right there. An estimate is not a promise. It should not be treated as such.
barrysteve 4y ago
Can you do it? Provide an estimate that's accurate and stick to it with the routinized scheduling of a blue collar job? It's not an apples to oranges comparison. You give me an architect's blueprint and guys who build to the legal building code, and I could probably get a house built. Expensive and painfully, but it can be done. I don't even know what the coding analog to an architect's blueprint is. They are fundamentally different jobs.
- WastingMyTime89 4y ago
  > Can you do it? Provide an estimate that's accurate and stick to it with the routinized scheduling of a blue collar job? Yes, I work as a delivery lead nowadays. Producing and respecting estimates for software projects is literally my job. I routinely fire developers who pretend they can’t do estimate and strangely the ones I keep are actually not only able to do it but good at it.
  - barrysteve 4y ago
    Fair enough. Guess I should admit you squarely got me.
  - firstlink 4y ago
    You just made two contradictory claims: (a) that your job is to produce estimates; (b) that the developers who you work with are the ones who need to "do" the estimates. I've met your sort before. You're a net waste of resources in an org: instead of developers getting things done, they're dealing with you asking them to do your job for you, i.e. produce estimates for the things they'll never actually get around to doing (because of producing estimates). Your username would be accurate if s/My/Everyone's/
    - WastingMyTime89 4y ago
      I produce estimates and coordinate eight concurrent projects involving ~70 people in cross functional teams. At some point, the actual domain experts have to give me their inputs so I can consolidate and prioritise things. Nothing contradictory here. If it helps you sleep at night, sure, assume I’m a net waste of ressource. Good luck fighting with the other seven teams for some time with the shared senior UX expert.
lamontcg 4y ago
> 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. My optimistic/pessimistic takes at my last job would look something like "roughly a week to roughly 2 years" Depends on how deep the yak shaving goes, and you wouldn't know until you got halfway through fixing the problem. Often I could take an educated guess as to which side of the scale it came down on, but I've definitely started pulling on a string inside of the codebase and it just kept going and going and going. All of those baked-in assumptions that other developers unconsciously made over the course of a decade can pile up into a mess that you just can't implement the feature/bugfix without doing a pile of potentially breaking changes that need to be shipped in major versions. Generally if I worked the problem for a week then I could give you a much better estimate of when it would be done, and often that estimate was "it's done now" after a week. But if I hadn't looked at that particular subsystem for a few years, I couldn't trust my memory of it up front and had to do exploratory surgery first. (Really exploratory surgery is a much better metaphor for what you're going to be doing, and surgeons can routinely find surprises -- "oh look that barely perceptible shadow on the x-ray turns out to be a stage 4 tumor...") Yes, the codebase was horrible, yes it needed to be cleaned up, no we didn't have the manpower to do that and it would have taken me 10 years to rewrite it all. Quitting of course was an excellent solution.
- firstlink 4y ago
  > Generally if I worked the problem for a week then I could give you a much better estimate of when it would be done, and often that estimate was "it's done now" after a week. You're lucky if your management chain allows you to work on problems for as long as a week without giving them an estimate first.
locustous 4y ago
> 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. Add a small feature to an existing system. This estimate can be anywhere from several months to a day. Most of the error bars are org and system specific rather than anything to do with the feature. The exact same feature built by the same person in different orgs and different systems can be opposite ends of the range. Seldom do people have the contextual understanding to provide an accurate narrow estimate, particularly since both org and system are in flux. They change constantly. Unseen landmines potentially await in both. > 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. And such orgs take forever to get anything done. > It still baffle me than approximately half of developers don’t understand things which are obvious to any seasoned blue collar worker. Software is probably the hardest kind of engineering you can do. All the system constraints are virtual. Just consider comparing a dirt ground for consistency and behavior vs libc... 304 stainless vs react. You can go deep in both, but a shallow understanding of one takes you much much further than a shallow understanding of the other.
- WastingMyTime89 4y ago
  > Add a small feature to an existing system. This estimate can be anywhere from several months to a day. That’s extremely untrue in my experience. Sure, hard to interface with systems are a thing and organisational roadblocks happen but an onboarded senior team member can tell you what’s going to take days and what’s going to take months or they have no business being senior in the first place. I feel like my answers in this discussion have been particularly harsh but I would really like people calling themselves software engineers to start acting like some. I think my view on this subject has been strongly shaped by spending most of my career doing software development for industrial companies: people who claim software is particularly complicated just don’t understand and respect how complex the rest of an industrial project is.
  - tremon 4y ago
    an onboarded senior team member can tell you You're making an unwarranted assumption here. There's many pieces of software that have no development team at all. There's no one to ask; the last person to touch this software left the company three years ago. All they can tell you about it is how they use it now. It's likely there's at least someone that can explain their business process to you, but identifying them and receiving enough of their time to piece the picture together is another story. And maybe, if you're lucky, that person can tell you what the business process was at the time the software was written, and what has changed since then. But this process can take weeks, and most of the time you're expected to provide an estimate before even talking to anyone from operations. Sure, for internal software with an active maintenance/development team, informed estimates can be given with a relatively high level of confidence. But as an outside consultant working with non-software companies, all estimates are completely made-up based on your reading of the buyer's budget: there are no other data points to base your estimate on.
magicalhippo 4y ago
> 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. Yeah, most of the time my boss just needs to know if this job is a few hours, a few days or a few weeks. I never answer with exact numbers, but a range. If there are some major unknowns I let him know. If I made some important assumptions then I let him know. Sometimes I'm wrong. Most of the time my estimates are sufficiently accurate. Sometimes the customer really needs this done before some deadline. Then it often turns into "how can we make this happen before then". After a bit of back and forth with some added assumptions and cutting functionality, we usually end up with a solution that can be realized in time.
deleted 4y ago
[deleted]
iamcasen 4y ago
Thank God somebody said this. When I was working as an IC, I would be very communicative, highlight the unknowns, and get buy-in from my boss. If a surprise came up, I would make sure everyone knew the game had changed. As a manager now, I get scoffed at if I even hint at a deadline. Excuse me what? We have a limited budget, a limited runway, and we need to prioritize which product bets we are going to make. This seems entirely logical, but a lot of devs I work with now find it impossible. They just enjoy tinkering away with whatever thing interests them, and delivering value only means what they personally find valuable. Personally, I find it a bit pathetic and childish. I say this as a long time software engineer who knows perfectly well how this business works.
- pylua 4y ago
  Will Wright had a quote on this … if you don’t have any constraints you are just playing. That said, however, The problem I run into during practice is dependencies— people want estimates to integrate into systems you have never heard of or used before. Not only that, there is no in place architecture or design before estimation. Imagine a construction company estimating a house without knowing how big it is or without having blueprints. Often times software development is designing and architecting the system — not just implementing it. And that is the expensive part.
  - mewpmewp2 4y ago
    Then you communicate! Say that the estimation can depend on the complexity of the system. I would think worst case is when the system has these A, B problems, then it would take N time. Otherwise best case it could take M time. If we want more accurate idea, we can spend O time on it to figure out what it could be.
    - pylua 4y ago
      I would say this is being negligent if it is generalized. Often times architecting a system involves meetings with multiple parties — stake holders , legal counsels, and months or years of planning ahead to give a proper estimate for a large system. Time and materials is the right way to do this. However I can see this working in a very small scenario.

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
  You mean we're all a special case :)
magicalhippo 4y ago
I just say that to my boss: "this would involve using a library/tool I've not yet used, so I cannot give a good estimate until I've spent some time digging into it. Right now I don't know if it will be easy or very difficult." If he really needs an estimate he'll tell me to start digging into it right away, and I'll let him know after a bit of time how it's going. If there are still large uncertainties and my boss still wants this completed by some specific date, we might try to explore alternative solutions.
- Scarblac 4y ago
  Yes it boils down to, if the person asking for estimates understands the problems with them, it's safe to try. With bad managers it's better not to give them as they will be abused. In the above case, I didn't get that time I would need, they wanted the estimate to include that time I would need to dig into it. But that's above my estimation powers. I didn't even know if what they asked was possible at all. They went and asked someone else who did guess some number of weeks, but the work never got priority so we still don't know.
  - magicalhippo 4y ago
    > they wanted the estimate to include that time I would need to dig into it Yeah that ain't gonna fly with me.
  - mewpmewp2 4y ago
    Did you say what you are saying here? Did you say that 1) Without knowing further best case is it takes N time, worst case M time, and if there are certain obstacles it could be completely unfeasible. 2) To get more accurate time and to understand whether it's feasible I would need O time to figure that out first, and I can give you the more accurate estimate then.
    - IIsi50MHz 4y ago
      This seems unexpectedly optimistic, to me. I'd think: best case = it's already done; worst case = it's impossible, but we don't know that until we've spent too much time and money on it; the "certain obstacles" are almost always uncertain or completely unknown; and the "O time to figure out [how much time it will take] is also unknowable until the "figuring" is already complete. Now, if this were manufacturing with well-known processes, then I feel I could use your formula.
lutorm 4y ago
estimates, which turn into deadlines Well, that's the problem right there. An estimate is not a promise. It should not be treated as such.

barrysteve 4y ago

Can you do it? Provide an estimate that's accurate and stick to it with the routinized scheduling of a blue collar job? It's not an apples to oranges comparison. You give me an architect's blueprint and guys who build to the legal building code, and I could probably get a house built. Expensive and painfully, but it can be done. I don't even know what the coding analog to an architect's blueprint is. They are fundamentally different jobs.

WastingMyTime89 4y ago
> Can you do it? Provide an estimate that's accurate and stick to it with the routinized scheduling of a blue collar job? Yes, I work as a delivery lead nowadays. Producing and respecting estimates for software projects is literally my job. I routinely fire developers who pretend they can’t do estimate and strangely the ones I keep are actually not only able to do it but good at it.
- barrysteve 4y ago
  Fair enough. Guess I should admit you squarely got me.
- firstlink 4y ago
  You just made two contradictory claims: (a) that your job is to produce estimates; (b) that the developers who you work with are the ones who need to "do" the estimates. I've met your sort before. You're a net waste of resources in an org: instead of developers getting things done, they're dealing with you asking them to do your job for you, i.e. produce estimates for the things they'll never actually get around to doing (because of producing estimates). Your username would be accurate if s/My/Everyone's/
  - WastingMyTime89 4y ago
    I produce estimates and coordinate eight concurrent projects involving ~70 people in cross functional teams. At some point, the actual domain experts have to give me their inputs so I can consolidate and prioritise things. Nothing contradictory here. If it helps you sleep at night, sure, assume I’m a net waste of ressource. Good luck fighting with the other seven teams for some time with the shared senior UX expert.

lamontcg 4y ago

> 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. My optimistic/pessimistic takes at my last job would look something like "roughly a week to roughly 2 years" Depends on how deep the yak shaving goes, and you wouldn't know until you got halfway through fixing the problem. Often I could take an educated guess as to which side of the scale it came down on, but I've definitely started pulling on a string inside of the codebase and it just kept going and going and going. All of those baked-in assumptions that other developers unconsciously made over the course of a decade can pile up into a mess that you just can't implement the feature/bugfix without doing a pile of potentially breaking changes that need to be shipped in major versions. Generally if I worked the problem for a week then I could give you a much better estimate of when it would be done, and often that estimate was "it's done now" after a week. But if I hadn't looked at that particular subsystem for a few years, I couldn't trust my memory of it up front and had to do exploratory surgery first. (Really exploratory surgery is a much better metaphor for what you're going to be doing, and surgeons can routinely find surprises -- "oh look that barely perceptible shadow on the x-ray turns out to be a stage 4 tumor...") Yes, the codebase was horrible, yes it needed to be cleaned up, no we didn't have the manpower to do that and it would have taken me 10 years to rewrite it all. Quitting of course was an excellent solution.

firstlink 4y ago
> Generally if I worked the problem for a week then I could give you a much better estimate of when it would be done, and often that estimate was "it's done now" after a week. You're lucky if your management chain allows you to work on problems for as long as a week without giving them an estimate first.

locustous 4y ago

> 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. Add a small feature to an existing system. This estimate can be anywhere from several months to a day. Most of the error bars are org and system specific rather than anything to do with the feature. The exact same feature built by the same person in different orgs and different systems can be opposite ends of the range. Seldom do people have the contextual understanding to provide an accurate narrow estimate, particularly since both org and system are in flux. They change constantly. Unseen landmines potentially await in both. > 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. And such orgs take forever to get anything done. > It still baffle me than approximately half of developers don’t understand things which are obvious to any seasoned blue collar worker. Software is probably the hardest kind of engineering you can do. All the system constraints are virtual. Just consider comparing a dirt ground for consistency and behavior vs libc... 304 stainless vs react. You can go deep in both, but a shallow understanding of one takes you much much further than a shallow understanding of the other.

WastingMyTime89 4y ago
> Add a small feature to an existing system. This estimate can be anywhere from several months to a day. That’s extremely untrue in my experience. Sure, hard to interface with systems are a thing and organisational roadblocks happen but an onboarded senior team member can tell you what’s going to take days and what’s going to take months or they have no business being senior in the first place. I feel like my answers in this discussion have been particularly harsh but I would really like people calling themselves software engineers to start acting like some. I think my view on this subject has been strongly shaped by spending most of my career doing software development for industrial companies: people who claim software is particularly complicated just don’t understand and respect how complex the rest of an industrial project is.
- tremon 4y ago
  an onboarded senior team member can tell you You're making an unwarranted assumption here. There's many pieces of software that have no development team at all. There's no one to ask; the last person to touch this software left the company three years ago. All they can tell you about it is how they use it now. It's likely there's at least someone that can explain their business process to you, but identifying them and receiving enough of their time to piece the picture together is another story. And maybe, if you're lucky, that person can tell you what the business process was at the time the software was written, and what has changed since then. But this process can take weeks, and most of the time you're expected to provide an estimate before even talking to anyone from operations. Sure, for internal software with an active maintenance/development team, informed estimates can be given with a relatively high level of confidence. But as an outside consultant working with non-software companies, all estimates are completely made-up based on your reading of the buyer's budget: there are no other data points to base your estimate on.

magicalhippo 4y ago

> 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. Yeah, most of the time my boss just needs to know if this job is a few hours, a few days or a few weeks. I never answer with exact numbers, but a range. If there are some major unknowns I let him know. If I made some important assumptions then I let him know. Sometimes I'm wrong. Most of the time my estimates are sufficiently accurate. Sometimes the customer really needs this done before some deadline. Then it often turns into "how can we make this happen before then". After a bit of back and forth with some added assumptions and cutting functionality, we usually end up with a solution that can be realized in time.

deleted 4y ago

[deleted]

iamcasen 4y ago

Thank God somebody said this. When I was working as an IC, I would be very communicative, highlight the unknowns, and get buy-in from my boss. If a surprise came up, I would make sure everyone knew the game had changed. As a manager now, I get scoffed at if I even hint at a deadline. Excuse me what? We have a limited budget, a limited runway, and we need to prioritize which product bets we are going to make. This seems entirely logical, but a lot of devs I work with now find it impossible. They just enjoy tinkering away with whatever thing interests them, and delivering value only means what they personally find valuable. Personally, I find it a bit pathetic and childish. I say this as a long time software engineer who knows perfectly well how this business works.

pylua 4y ago
Will Wright had a quote on this … if you don’t have any constraints you are just playing. That said, however, The problem I run into during practice is dependencies— people want estimates to integrate into systems you have never heard of or used before. Not only that, there is no in place architecture or design before estimation. Imagine a construction company estimating a house without knowing how big it is or without having blueprints. Often times software development is designing and architecting the system — not just implementing it. And that is the expensive part.
- mewpmewp2 4y ago
  Then you communicate! Say that the estimation can depend on the complexity of the system. I would think worst case is when the system has these A, B problems, then it would take N time. Otherwise best case it could take M time. If we want more accurate idea, we can spend O time on it to figure out what it could be.
  - pylua 4y ago
    I would say this is being negligent if it is generalized. Often times architecting a system involves meetings with multiple parties — stake holders , legal counsels, and months or years of planning ahead to give a proper estimate for a large system. Time and materials is the right way to do this. However I can see this working in a very small scenario.