3 ms·

I don't agree with the "no estimates" sentiment. My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and

I don't agree with the "no estimates" sentiment. My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.

hannofcart 4y ago
This is how we do estimates. Nothing set in stone, all just a rough guide. However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine. Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.
- noirbot 4y ago
  The difference is you're hiring most other trades-people to do a generally fairly routine bit of work and then be done. A lot of programming is about doing unroutine work that has no clearly defined end-state. I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.
- jesstaa 4y ago
  Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.
  - ilaksh 4y ago
    Architect designing home is the wrong metaphor. Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes. Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.
    - pillefitz 4y ago
      Depends, really. Most software is doing basic CRUD and efforts can be estimated reasonably well. Some other software, like your example suggests, is literally rocket science. But even here estimates are typically not too far off.
    - Kinrany 4y ago
      > Buildings do not have moving parts. Of course they do: people, furniture, water, air, heat.
    - hannofcart 4y ago
      > Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. If programming indeed was "usually" like that, then there shouldn't be much software getting produced at all. Since building "a new type of interdimensional alien spacecraft engine" is something that's very very unusual, to say the least. :)
quickthrower2 4y ago
I also don't agree with no estimates. The problem is I see estimates like this; $COMPLEX_REQUIREMENT: 12 days BACK END - 3 days FRONT END - 3 days UNIT TEST - 2 days ... Which is almost certainly gonna be wrong, so it useless. But "12" is a number and number can be added. We have 274 man days this quarter, and of course we allow time for bugs and leave and stuff, so sum of estimates is 263, so that's our plan for the next 3 months. Never works. Estimates are useful for making branch decisions though. So knowing is it 1 hour or 1 day or 1 week or 1 month or 1 year (which is closest) is useful for deciding if it is done (hint if it involves code at all then not 1 hour!) For each category, accept it might take up to 5 times as long. So 1 day = 1 to 5 days. 1 week = 1 to 5 weeks and so on. Is it a disaster if the thing took 5 weeks? Id there another "1 week" tasks that is more urgent than the one you are thinking of doing next? That is the level. Then don't track too closely how long it takes .. BUT ... maybe have a team leader flag at 2.5x estimate to discuss in depth if it is worth carrying on. In addition to standups/whatever to get unblocked or report the estimate was way off. In a nutshell treat the estimate as a decision heuristic. But not as a developer skill measurement tool, or a timeline delivery. If you have a real deadline, then presumably you agreed to it (some contract) and hopefully when coming to that agreement technical people were consulted, and loads and loads of buffer was included. It is like agreeing to host people on Christmas day - it will probably need say 20 hours of prep, but arranging it 3 months ahead of time and slowly working on it the whole time is a surefire way of success. Starting the project on 23rd Dec is a surefire way to fail. Common sense in real life (because we use common sense not trying to "optimise" every last second). Also in real life if other things mean you can't host Christmas ... you don't agree to the deadline. Let's book a table at the pub. That is what you do. Companies tend not to do that, they agree to all kinds of silly things. And you get silly deadlines, and bullshit estimates as a result.

hannofcart 4y ago

This is how we do estimates. Nothing set in stone, all just a rough guide. However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine. Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.

noirbot 4y ago
The difference is you're hiring most other trades-people to do a generally fairly routine bit of work and then be done. A lot of programming is about doing unroutine work that has no clearly defined end-state. I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.
jesstaa 4y ago
Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.
- ilaksh 4y ago
  Architect designing home is the wrong metaphor. Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes. Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.
  - pillefitz 4y ago
    Depends, really. Most software is doing basic CRUD and efforts can be estimated reasonably well. Some other software, like your example suggests, is literally rocket science. But even here estimates are typically not too far off.
  - Kinrany 4y ago
    > Buildings do not have moving parts. Of course they do: people, furniture, water, air, heat.
  - hannofcart 4y ago
    > Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. If programming indeed was "usually" like that, then there shouldn't be much software getting produced at all. Since building "a new type of interdimensional alien spacecraft engine" is something that's very very unusual, to say the least. :)

quickthrower2 4y ago

I also don't agree with no estimates. The problem is I see estimates like this; $COMPLEX_REQUIREMENT: 12 days BACK END - 3 days FRONT END - 3 days UNIT TEST - 2 days ... Which is almost certainly gonna be wrong, so it useless. But "12" is a number and number can be added. We have 274 man days this quarter, and of course we allow time for bugs and leave and stuff, so sum of estimates is 263, so that's our plan for the next 3 months. Never works. Estimates are useful for making branch decisions though. So knowing is it 1 hour or 1 day or 1 week or 1 month or 1 year (which is closest) is useful for deciding if it is done (hint if it involves code at all then not 1 hour!) For each category, accept it might take up to 5 times as long. So 1 day = 1 to 5 days. 1 week = 1 to 5 weeks and so on. Is it a disaster if the thing took 5 weeks? Id there another "1 week" tasks that is more urgent than the one you are thinking of doing next? That is the level. Then don't track too closely how long it takes .. BUT ... maybe have a team leader flag at 2.5x estimate to discuss in depth if it is worth carrying on. In addition to standups/whatever to get unblocked or report the estimate was way off. In a nutshell treat the estimate as a decision heuristic. But not as a developer skill measurement tool, or a timeline delivery. If you have a real deadline, then presumably you agreed to it (some contract) and hopefully when coming to that agreement technical people were consulted, and loads and loads of buffer was included. It is like agreeing to host people on Christmas day - it will probably need say 20 hours of prep, but arranging it 3 months ahead of time and slowly working on it the whole time is a surefire way of success. Starting the project on 23rd Dec is a surefire way to fail. Common sense in real life (because we use common sense not trying to "optimise" every last second). Also in real life if other things mean you can't host Christmas ... you don't agree to the deadline. Let's book a table at the pub. That is what you do. Companies tend not to do that, they agree to all kinds of silly things. And you get silly deadlines, and bullshit estimates as a result.