4 ms·

I think it boils down to this. 1. If you are doing something that people have done before, then it is possible to come up with a reasonable estimate. How? Just

by gh1 10y ago

I think it boils down to this. 1. If you are doing something that people have done before, then it is possible to come up with a reasonable estimate. How? Just talk with someone who has done something similar before and they will help you understand the complexity involved. Example : Rubik's cube. 2. If you are doing something that no one has done before, then it is more difficult to come up with an estimate. Example: Unified theory of forces. In the 1970, people assumed that we are very close. It's been 45 years since then and we aren't any closer. Of course, I have often made the mistake of underestimating tasks of type 1 because I didn't talk to anyone with enough experience. Maybe this has to do with self confidence. I am very confident of my abilities so I usually tend to underestimate things rather than overestimate them.

the_duke 10y ago
Even 1.) is very hard to estimate, and info from people who did something similar is of quite limited value. Skills, technical environment (system, programming language, libraries, available tooling) and team efficiency vary A LOT. -- Regarding your comment of overestimation: I think this is a problem for almost everyone. When you get a task described, you often think "hey, this will be easy", without understanding all the requirements in detail, the complexity it will entail or the broader effects in a system. That's where only experience can help (your own or someone elses input)
- gh1 10y ago
  On a different note, I have heard it being said that it is better to overestimate than underestimate. This is apparently the best way to manage other people's expectations and maintain credibility.
  - matwood 10y ago
    Over is probably the wrong word. I call it realistic estimation. Every stakeholder/business person wants it done yesterday. Their job is to push and prod and squeeze out as much efficiency as possible. It's the estimators job to give a realistic estimate, which often means pushing back to a lot of pressure, and that can be very hard. It's important to realize the most important thing for the business is an estimate as close to reality as possible though. This point is often missed when there is pressure to estimate it shorter, when in fact it is not the estimate the business person wants shorter, but the complete task. And yes, it does take time to build that trust. Often times when I'm at a new company, the business people are used to short estimates and overruns. I have to train them to understand that while my estimates are longer, they are typically closer to correct. It only takes once or twice of having something done when expected to win them over.
    - MaulingMonkey 10y ago
      > Over is probably the wrong word. I call it realistic estimation. I generate realistic estimations by attempting to overestimate and failing to do so sufficiently. Watching coworkers try to estimate how long it'll take to deliver software really makes you wonder if pessimists actually exist, or if they're rather some kind of myth or mirage.
matwood 10y ago
With regards to 1, the beauty of software is you're almost never doing exactly something that has been done before else you would not have to do it. It may be similar or close in a lot of ways, but those differences are where schedules and budgets go to die. The best we can do is break tasks that we know about into tiny chunks and estimate those. Then, as we are working and discover the unknown unknowns, break those down and estimate those.

by gh1 10y ago

the_duke 10y ago

Even 1.) is very hard to estimate, and info from people who did something similar is of quite limited value. Skills, technical environment (system, programming language, libraries, available tooling) and team efficiency vary A LOT. -- Regarding your comment of overestimation: I think this is a problem for almost everyone. When you get a task described, you often think "hey, this will be easy", without understanding all the requirements in detail, the complexity it will entail or the broader effects in a system. That's where only experience can help (your own or someone elses input)

gh1 10y ago
On a different note, I have heard it being said that it is better to overestimate than underestimate. This is apparently the best way to manage other people's expectations and maintain credibility.
- matwood 10y ago
  Over is probably the wrong word. I call it realistic estimation. Every stakeholder/business person wants it done yesterday. Their job is to push and prod and squeeze out as much efficiency as possible. It's the estimators job to give a realistic estimate, which often means pushing back to a lot of pressure, and that can be very hard. It's important to realize the most important thing for the business is an estimate as close to reality as possible though. This point is often missed when there is pressure to estimate it shorter, when in fact it is not the estimate the business person wants shorter, but the complete task. And yes, it does take time to build that trust. Often times when I'm at a new company, the business people are used to short estimates and overruns. I have to train them to understand that while my estimates are longer, they are typically closer to correct. It only takes once or twice of having something done when expected to win them over.
  - MaulingMonkey 10y ago
    > Over is probably the wrong word. I call it realistic estimation. I generate realistic estimations by attempting to overestimate and failing to do so sufficiently. Watching coworkers try to estimate how long it'll take to deliver software really makes you wonder if pessimists actually exist, or if they're rather some kind of myth or mirage.

matwood 10y ago

With regards to 1, the beauty of software is you're almost never doing exactly something that has been done before else you would not have to do it. It may be similar or close in a lot of ways, but those differences are where schedules and budgets go to die. The best we can do is break tasks that we know about into tiny chunks and estimate those. Then, as we are working and discover the unknown unknowns, break those down and estimate those.