4 ms·

As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train fo

As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years. Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless". In the places I've worked as a manager, with the managers, directors, and VPs I've worked with, I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI. Developer time is a limited and incredibly expensive resource at most companies and managers need to make sure it's used in the most impactful way that it can be. A project may make sense to do if it's going to take a month, but it may not make sense to do if it's going to take a year. Without some sort of estimate on the time a project will take, you can't properly prioritize work. There are absolutely projects where it's just like, we need to get this done no matter how long it takes, but most projects aren't like that. Again, I totally get your frustrations, but the thing I always tell my teams is let's say you wanted to build a house from scratch. You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done." I doubt you would hire them, right? You need more information than that to be able to truly make a decision because at a certain dollar value it's just not worth it anymore. You don't need an exact dollar amount, but knowing whether it's going to cost $100k or $500k will completely change the value proposition. Again, I totally feel where you're coming from with pushing back on estimates, but I don't think you're ever going to get away from them. With that in mind, one of the things I've started asking my teams to do where they're really pushing back on estimating is to take a day and think on it and then come back and give me two numbers. Give me an estimate that you're 90% sure is too high and a second estimate that you're 90% sure is too low. I've feel like that takes some of the pressure off because there's no exact number that they can be held to and it gives me enough info to make a decision.

godelski 2y ago
Why not then be honest about what kind of estimate is being made? How about saying "Can you give me ballpark estimates? On the order of days, weeks, months, years?" Then everyone knows it is a rough estimate and no one is forced to make impossible promises and trying to do the dumb "what I think multiply by 3" or whatever stuff goes on. Framed as ballpark or "rough" there's a clearer sense of shared ambiguity
- stavros 2y ago
  I feel like this is the crux of the issue. Dev estimates should be taken with large error bars, and I think the entire problem is caused by people who take them at face value, making developers not want to give estimates at all next time.
  - prerok 2y ago
    Well, it helps if you have retrospectives, though I see them rarely done properly. What kind of works is tracking similar efforts (in the same code base) and measuring how long they take. While every task is different, there are usually a small number of different classes of tasks, and knowing how quickly these can be done helps in both estimating as well as defending the estimates.
- superfrank 2y ago
  Personally, I almost always do. You're right one of the big problems is that people treat estimates as commitments and they're not that. They're called estimates because it's an estimate not a certainty. That isn't an issue with the estimates themselves though. It's a culture issue. Saying estimates are useless and I'm not going to do them because my company treats them as commitments is throwing the baby out with the bathwater, IMO.
jdwithit 2y ago
> You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done." I see you haven't needed to hire many building contractors. "I won't know until I'm done" wasn't how the engagements started, but it's how they all ended up. When the budget's gone and they're only halfway done what are you gonna do, live with a hole in the wall and no running water? If you got a home renovation done on time or on budget (I refuse to believe both), congrats on catching a unicorn.
- hinkley 2y ago
  Even before I owned a house, I had watched enough This Old House to know how completely out of touch GP’s assertion was.
- superfrank 2y ago
  I actually have. I'm completly remodeling a rental property after a nightmare tenant. I'm totally familiar with what you're talking about and am not disagreeing, but my point was more that they still give you an estimate. I've never had a contractor or someone he's hired not provide an estimate. I know their number is going to be off, so personally, I mentally double any number they tell me, but having that starting point is important. If they tell me it's going to be $6k for a new kitchen, I can budget $12k. If they just went ¯\_(ツ)_/¯ then I don't even have a starting point which is way less helpful.
isoprophlex 2y ago
Your analogy falls flat, because building software is not the same as building a house. In fact, unusual construction projects with unknown dependencies and shifting requirements are just as unplannable as software development, and are just as liable to go over budget.
- superfrank 2y ago
  I know construction projects regularly go over budget, but they still give estimates. That's my entire point. Why do software engineers feel their domain is special. Projects across all domains face the same problems we do and yet the only domain I can think of where it's normal to not provide an estimate for work up front is US health care pricing and just about everyone has a pretty major issue with the way that is run.
hinkley 2y ago
I think you’ve forgotten how this goes already. “What’s your estimate? No, that won’t work.” Don’t ever start that bullshit conversation with people. You’ve now signaled that they can’t trust you and now any “information” they give you will now be untrustworthy because you’re untrustworthy and turnabout is fair play. If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time. And if you don’t get any nice to haves in that initial estimate you might as well pull the plug now because everyone knows that scope will have to be shed to hit the date. And that we try to pretend anything different is happening is part of that illusion of control thing GP mentioned. If we can’t build a thing by whenever then it’s time to rethink the project. A different approach, possibly involving buying part of the solution instead of building the whole thing. Or we do some other project first that will teach us how to do this project better.
- superfrank 2y ago
  > "What’s your estimate? No, that won’t work" That's a different problem though. The issue isn't that estimating the project is useless, it's that you work with people who don't respect the estimate and think it's a negotiation. I get that you're saying that in that situation the only winning move it to not play, but that issue you're identifying isn't actually an issue with the estimate itself. > If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time I get what you're saying and it's a valid suggestion, but personally, I find it better to work the other way. Engineer estimates a best case scenario with all the bells and whistles and then it becomes a discussion with stakeholders as to what can be cut to fit the timeline. The reason I think that is better is because most of the time features that an engineer priorities may not align with what stakeholders priorities or there maybe tradeoffs a stakeholder is willing to make once they see estimates. For example A stakeholder may say, I really want it to do X, so the engineer comes back and says X will take 2 months to build and that's that, but if the stakeholder has the full project estimate in front of them, they might go, I really wanted X, but it looks like we can do A, B, and C in the same amount of time as X and those three things combined would be more impactful than X, so let's do that instead. Again, you're suggestion is totally valid and I'm sure many people do it that way, but I've gotten better results the other way.
imiric 2y ago
I understand and sympathize with the managerial PoV as well. :) It doesn't make the exercise of estimates any less pointless, though. > I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI. Don't get me wrong. I didn't mean "control" in the sense that they want power over the project. It's more that they want to feel that these processes make the project more predictable than it would be without them. This is what I argue is a fallacy. Whatever estimates they get back from the dev team, and whatever extrapolated metrics like "velocity" they think help them get a feel for the team's productivity, is ultimately pointless. The problem is that these metrics are relied upon, when they're really no more reliable than not tracking them. Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project. Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other. This is not like building a house, where most houses have something in common. This is like inventing an entirely new way to build a house, from entirely different components, every time. The problems you run into each time are wildly different. Even when using the same programming languages, frameworks and APIs, the interaction between all of these changes every time you put them together. But I'm sure you know all this. I'm just saying that the exercise of estimates is pointless, and the value they bring to the company is an illusion.
- superfrank 2y ago
  > Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project. I fully disagree with that. Yes, you can absolutely rely on physics to be predictable in physical engineering, but I'd estimate there are similar consistencies in software engineering. You know how long things like the built time take and you can get averages on PR and design doc review times. There are going to be parts of a project that aren't full of unknowns that you can probably accurately predict (e.g. I have to change the color and text of a button or I need to spin up a new Redis instances and did that same thing on my last project). If you're building a house though, there are plenty of things you can't predict, same as with engineering. You can estimate how much concrete costs, but if you're supplier is in Canada and all of the sudden there's a 25% tariff slapped on the import your cost estimate could be fucked. Alternatively, what if the bricklayer breaks their arm a week before they're scheduled to start? In almost every project in almost every discipline there are unknown unknowns, but that doesn't stop them from providing estimates. > Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other. I mentioned it above, but I could not disagree with this more and if you really feel this way, I think you're not thinking things through. If I build an API endpoint to return all users from a database, I can probably pretty accurately predict how long it would take to build an endpoint to return a single user from that same database. If you did a project to build the front end of a sign in page, you can probably pretty accurately predict how long building the front end of a sign up page would take. Even on projects where the project itself is fairly novel, not every part of the project will be and that can be a starting point. Even if you're building something entirely new, if you know you need to add a new database table, you might need to look at what their migration framework looks like, but you can probably get a fairly accurate estimate on the time it takes to do that part. Most software projects aren't 100% work that you've never done before and even estimating that work can be a good starting point and be helpful. I also really disagree with the idea that just because it's physical means it's predictable. Concrete drys slower in cold weather, so unless you have a 100% accurate weather prediction there's unknowns there. You may estimate it's going to take 5 days to build the framing, but if a freak snowstorm happens and your crew now spends the first and last hour of the day shoveling snow and covering/uncovering everything on the build site, your estimate is out the window. Even ignoring that, it's not like building a house is a completely automated process. Even if you know exactly how long the concrete will take to dry there's a lot of people involved in the process of pouring it.

godelski 2y ago

Why not then be honest about what kind of estimate is being made? How about saying "Can you give me ballpark estimates? On the order of days, weeks, months, years?" Then everyone knows it is a rough estimate and no one is forced to make impossible promises and trying to do the dumb "what I think multiply by 3" or whatever stuff goes on. Framed as ballpark or "rough" there's a clearer sense of shared ambiguity

stavros 2y ago
I feel like this is the crux of the issue. Dev estimates should be taken with large error bars, and I think the entire problem is caused by people who take them at face value, making developers not want to give estimates at all next time.
- prerok 2y ago
  Well, it helps if you have retrospectives, though I see them rarely done properly. What kind of works is tracking similar efforts (in the same code base) and measuring how long they take. While every task is different, there are usually a small number of different classes of tasks, and knowing how quickly these can be done helps in both estimating as well as defending the estimates.
superfrank 2y ago
Personally, I almost always do. You're right one of the big problems is that people treat estimates as commitments and they're not that. They're called estimates because it's an estimate not a certainty. That isn't an issue with the estimates themselves though. It's a culture issue. Saying estimates are useless and I'm not going to do them because my company treats them as commitments is throwing the baby out with the bathwater, IMO.

jdwithit 2y ago

> You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done." I see you haven't needed to hire many building contractors. "I won't know until I'm done" wasn't how the engagements started, but it's how they all ended up. When the budget's gone and they're only halfway done what are you gonna do, live with a hole in the wall and no running water? If you got a home renovation done on time or on budget (I refuse to believe both), congrats on catching a unicorn.

hinkley 2y ago
Even before I owned a house, I had watched enough This Old House to know how completely out of touch GP’s assertion was.
superfrank 2y ago
I actually have. I'm completly remodeling a rental property after a nightmare tenant. I'm totally familiar with what you're talking about and am not disagreeing, but my point was more that they still give you an estimate. I've never had a contractor or someone he's hired not provide an estimate. I know their number is going to be off, so personally, I mentally double any number they tell me, but having that starting point is important. If they tell me it's going to be $6k for a new kitchen, I can budget $12k. If they just went ¯\_(ツ)_/¯ then I don't even have a starting point which is way less helpful.

isoprophlex 2y ago

Your analogy falls flat, because building software is not the same as building a house. In fact, unusual construction projects with unknown dependencies and shifting requirements are just as unplannable as software development, and are just as liable to go over budget.

superfrank 2y ago
I know construction projects regularly go over budget, but they still give estimates. That's my entire point. Why do software engineers feel their domain is special. Projects across all domains face the same problems we do and yet the only domain I can think of where it's normal to not provide an estimate for work up front is US health care pricing and just about everyone has a pretty major issue with the way that is run.

hinkley 2y ago

I think you’ve forgotten how this goes already. “What’s your estimate? No, that won’t work.” Don’t ever start that bullshit conversation with people. You’ve now signaled that they can’t trust you and now any “information” they give you will now be untrustworthy because you’re untrustworthy and turnabout is fair play. If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time. And if you don’t get any nice to haves in that initial estimate you might as well pull the plug now because everyone knows that scope will have to be shed to hit the date. And that we try to pretend anything different is happening is part of that illusion of control thing GP mentioned. If we can’t build a thing by whenever then it’s time to rethink the project. A different approach, possibly involving buying part of the solution instead of building the whole thing. Or we do some other project first that will teach us how to do this project better.

superfrank 2y ago
> "What’s your estimate? No, that won’t work" That's a different problem though. The issue isn't that estimating the project is useless, it's that you work with people who don't respect the estimate and think it's a negotiation. I get that you're saying that in that situation the only winning move it to not play, but that issue you're identifying isn't actually an issue with the estimate itself. > If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time I get what you're saying and it's a valid suggestion, but personally, I find it better to work the other way. Engineer estimates a best case scenario with all the bells and whistles and then it becomes a discussion with stakeholders as to what can be cut to fit the timeline. The reason I think that is better is because most of the time features that an engineer priorities may not align with what stakeholders priorities or there maybe tradeoffs a stakeholder is willing to make once they see estimates. For example A stakeholder may say, I really want it to do X, so the engineer comes back and says X will take 2 months to build and that's that, but if the stakeholder has the full project estimate in front of them, they might go, I really wanted X, but it looks like we can do A, B, and C in the same amount of time as X and those three things combined would be more impactful than X, so let's do that instead. Again, you're suggestion is totally valid and I'm sure many people do it that way, but I've gotten better results the other way.

imiric 2y ago

I understand and sympathize with the managerial PoV as well. :) It doesn't make the exercise of estimates any less pointless, though. > I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI. Don't get me wrong. I didn't mean "control" in the sense that they want power over the project. It's more that they want to feel that these processes make the project more predictable than it would be without them. This is what I argue is a fallacy. Whatever estimates they get back from the dev team, and whatever extrapolated metrics like "velocity" they think help them get a feel for the team's productivity, is ultimately pointless. The problem is that these metrics are relied upon, when they're really no more reliable than not tracking them. Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project. Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other. This is not like building a house, where most houses have something in common. This is like inventing an entirely new way to build a house, from entirely different components, every time. The problems you run into each time are wildly different. Even when using the same programming languages, frameworks and APIs, the interaction between all of these changes every time you put them together. But I'm sure you know all this. I'm just saying that the exercise of estimates is pointless, and the value they bring to the company is an illusion.

superfrank 2y ago
> Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project. I fully disagree with that. Yes, you can absolutely rely on physics to be predictable in physical engineering, but I'd estimate there are similar consistencies in software engineering. You know how long things like the built time take and you can get averages on PR and design doc review times. There are going to be parts of a project that aren't full of unknowns that you can probably accurately predict (e.g. I have to change the color and text of a button or I need to spin up a new Redis instances and did that same thing on my last project). If you're building a house though, there are plenty of things you can't predict, same as with engineering. You can estimate how much concrete costs, but if you're supplier is in Canada and all of the sudden there's a 25% tariff slapped on the import your cost estimate could be fucked. Alternatively, what if the bricklayer breaks their arm a week before they're scheduled to start? In almost every project in almost every discipline there are unknown unknowns, but that doesn't stop them from providing estimates. > Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other. I mentioned it above, but I could not disagree with this more and if you really feel this way, I think you're not thinking things through. If I build an API endpoint to return all users from a database, I can probably pretty accurately predict how long it would take to build an endpoint to return a single user from that same database. If you did a project to build the front end of a sign in page, you can probably pretty accurately predict how long building the front end of a sign up page would take. Even on projects where the project itself is fairly novel, not every part of the project will be and that can be a starting point. Even if you're building something entirely new, if you know you need to add a new database table, you might need to look at what their migration framework looks like, but you can probably get a fairly accurate estimate on the time it takes to do that part. Most software projects aren't 100% work that you've never done before and even estimating that work can be a good starting point and be helpful. I also really disagree with the idea that just because it's physical means it's predictable. Concrete drys slower in cold weather, so unless you have a 100% accurate weather prediction there's unknowns there. You may estimate it's going to take 5 days to build the framing, but if a freak snowstorm happens and your crew now spends the first and last hour of the day shoveling snow and covering/uncovering everything on the build site, your estimate is out the window. Even ignoring that, it's not like building a house is a completely automated process. Even if you know exactly how long the concrete will take to dry there's a lot of people involved in the process of pouring it.