4 ms·

All of these are familiar, unfortunately. Just one nitpick: > Proper estimations take time. IME there's no such thing as "proper" estimations. They're all a w

by imiric 2y ago

All of these are familiar, unfortunately. Just one nitpick: > Proper estimations take time. IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion. Software development is inherently chaotic. Every task is different from another, and developers can only get a sense of the time and effort requirements once they start working on something. And these are constantly changing during development. It might take a long time to discover that a bug can be fixed by a single line change, or a chain of bugs might be discovered that need separate investigation, or a bug might not exist at all, etc. Every case is different. Additionally, every engineer is different, and they're different from themselves every time. Tasks that require mental effort are unpredictable by definition. Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless. They only serve to demotivate development teams when they're not met. I wish the industry would move on from them and adopt the more sensible approach of "it's done when it's done". Unfortunately, this doesn't gel with the rest of the business which functions on deadlines, so here we are.

superfrank 2y ago
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
You can tell they aren’t proper because if they were you’d finish half the stories ahead of the estimate and half after. The moment you get judged on your estimates they lose all value.

by imiric 2y ago

superfrank 2y ago

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

You can tell they aren’t proper because if they were you’d finish half the stories ahead of the estimate and half after. The moment you get judged on your estimates they lose all value.