4 ms·

People have a tremendously distorted view of reality due to their own biases. Myself definitely included. "It is difficult to get a man to understand something,

People have a tremendously distorted view of reality due to their own biases. Myself definitely included. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" - Upton Sinclair More concretely in the field of software engineering: Accurate, precise estimates are more expensive than the actual task itself. If someone asks you "how long until it is done", the only reasonable answer is just as long as you've already spent, even if you're close to the end of the project. a "three week project" on week 3 will most likely take another 3 weeks, all else being equal. Nobody has any idea, they're just making it up as they go along. If you do the math, you're ahead of almost everyone. Most people won't do math to save their own life. Same goes for reading. If you actually read documentation or source code, you're in a very slim minority. Most people just google.

TomVDB 7y ago
However... Inaccurate, optimistic estimates are often a feature. Many projects that turn out to be very valuable in the end would never have been started if the real time to completion had been communicated right from the start.
BlueTemplar 7y ago
Yeah, when we were taught (software) project management with GANTT, I smelled bullshit due to the lack of tolerance of uncertainty in the tool. Thankfully the exam "subverted our expectations" and strongly hinted that "no plan survives contact with the enemy".
- juped 7y ago
  "Gantt" is a person's name (Henry Gantt), not an acronym.
  - BlueTemplar 7y ago
    Damn, did I miss that or did they forgot to tech that ? Thanks anyway !
pandler 7y ago
> Nobody has any idea, they're just making it up as they go along. Ha! I came here to say this, and I'm glad you share my opinion. I realize that you're speaking specifically about software estimates, so please excuse me while I take your statement out of context and generalize it to most everything that I've experienced working in software. I'm biased in my views on this at this point, but I tend to notice people falling into two camps (on a spectrum of course): those who are most comfortable with well-defined tasks and low uncertainty, and those who are comfortable making stuff up and running with it. That's a rough, one-dimensional reduction of many qualities, including creativity, certain types of critical thinking, pragmatism, "self-starter"-ness, enthusiasm, etc. In equilibrium, it's the people who are able to distill uncertainty into something resembling certainty that ultimately provide tasks for the people less comfortable with unknowns. Corollary to that is the idea that "correct" is not binary but rather a measure of effectiveness by any number of shifting metrics (e.g. performance, readability/maintainability, "correctness", time and money cost, defect tolerance; all under the general umbrella of priorities). It's one of the things I try to impress most upon junior developers that I mentor, especially when they are just out of bootcamp and haven't learned yet that most problems aren't well defined and don't have an answer in the back of the book, if you would. Essentially, our job is to "make stuff up": always "how", and often "what".
- WJW 7y ago
  I don't think that it's actually true though. There are definitely areas where I don't have to make it up (anymore, at least). As a trivial example, implementing yet another API endpoint for a web form or something is not something where I have to experiment a lot (anymore). It's also important to realize that in most fields, people are definitely not just making it up as they go along. A dentist or an airline pilot has extensive training, knows what they are doing and why. This is even true when it comes to estimation tasks.
  - daze42 7y ago
    This seems accurate to me. Maybe the parent is speaking from a place in the Valley of Despair on the Dunning-Kruger curve. The good news is, they're just passing through.
prometheus76 7y ago
The other problem with estimates of time with regard to certain tasks is the pareto principle. Specifically, if I give it to this developer, it will take two days. If I give it to that developer, it will take two weeks. So, how long will it take?
- hnick 7y ago
  Problem is, if you always give it to the two-day developer your two-week developer might miss out on chances to improve. One place I worked just billed the client what we would as the reasonable rate and tracked the rest as training. I guess pair programming is one approach to get around this, you'd probably consume a week of dev time total in your example but it's better than two.
DannyB2 7y ago
> Accurate, precise estimates are more expensive than the actual task itself. That! That is is. You CAN get accurate estimates. But the cost of doing so is infeasible for any significant project. You can break things down into smaller pieces, easier to estimate. But the bigger the overall complexity, the more small pieces you will miss or fail to see. Or fail to see how parts interact. Or fail to recognize how far the influence of some element may reach. And other reasons estimates turn out wrong. The difficulty of software estimation was recognized in the 1960's. Again in the 1980s during the microcomputer revolution. And again sometimes more recently. When even the biggest companies, with vast resources, and billions of dollars cannot estimate when their product will be ready, how is a small software team expected to precisely do so. There was a joke of which year Windows 95 would ship in. At the same time, a business needs some kind of timetable because many other things need to coordinate with the completion of a software project. Maybe recognize the best you can do is have an idea of how well things are going. As a project gets further along you get a better idea of when it will be complete -- especially when there are lots of unknowns. When constructing a building, there are lots of knowns. How many square feet. How many walls. Electrical outlets. Plumbing fixtures. Etc, etc. They can give you a very good estimate. It's all things they've done before. Software is generally things that you've not done before. (or you may suffer the second system effect if it is)
- sbarre 7y ago
  After doing this for 25 years, I always say "you never get good at estimating, you just get less shitty at it".. Lots of people don't like that statement, but I stand by it.. I eventually stopped trying to estimate time required to deliver a specific thing, and instead started working backwards and seeing what can be done in the time we have. It's still estimating, but it's somehow a bit easier, especially if you're willing/able to re-evaluate along the way. I know that's basically Agile but I removed all the ritualistic BS. ;-)
  - DannyB2 7y ago
    After almost 40 years of doing this, I can agree that you do get better at it. But perfection never seems to materialize. Even if I get better at it, a lot of my younger coworkers do not. So the phenomena seems to continue.
hnick 7y ago
I've seen a corollary in my work with legacy system migrations and technical debt. Often scoping the work and taking so much care to not cause any issues grinds the work to a halt. We could do well with taking a bit more of a risk&fix attitude (after all, leaving it as it is constitutes a BIG risk over an infinite time frame).

TomVDB 7y ago

However... Inaccurate, optimistic estimates are often a feature. Many projects that turn out to be very valuable in the end would never have been started if the real time to completion had been communicated right from the start.

BlueTemplar 7y ago

Yeah, when we were taught (software) project management with GANTT, I smelled bullshit due to the lack of tolerance of uncertainty in the tool. Thankfully the exam "subverted our expectations" and strongly hinted that "no plan survives contact with the enemy".

juped 7y ago
"Gantt" is a person's name (Henry Gantt), not an acronym.
- BlueTemplar 7y ago
  Damn, did I miss that or did they forgot to tech that ? Thanks anyway !

pandler 7y ago

> Nobody has any idea, they're just making it up as they go along. Ha! I came here to say this, and I'm glad you share my opinion. I realize that you're speaking specifically about software estimates, so please excuse me while I take your statement out of context and generalize it to most everything that I've experienced working in software. I'm biased in my views on this at this point, but I tend to notice people falling into two camps (on a spectrum of course): those who are most comfortable with well-defined tasks and low uncertainty, and those who are comfortable making stuff up and running with it. That's a rough, one-dimensional reduction of many qualities, including creativity, certain types of critical thinking, pragmatism, "self-starter"-ness, enthusiasm, etc. In equilibrium, it's the people who are able to distill uncertainty into something resembling certainty that ultimately provide tasks for the people less comfortable with unknowns. Corollary to that is the idea that "correct" is not binary but rather a measure of effectiveness by any number of shifting metrics (e.g. performance, readability/maintainability, "correctness", time and money cost, defect tolerance; all under the general umbrella of priorities). It's one of the things I try to impress most upon junior developers that I mentor, especially when they are just out of bootcamp and haven't learned yet that most problems aren't well defined and don't have an answer in the back of the book, if you would. Essentially, our job is to "make stuff up": always "how", and often "what".

WJW 7y ago
I don't think that it's actually true though. There are definitely areas where I don't have to make it up (anymore, at least). As a trivial example, implementing yet another API endpoint for a web form or something is not something where I have to experiment a lot (anymore). It's also important to realize that in most fields, people are definitely not just making it up as they go along. A dentist or an airline pilot has extensive training, knows what they are doing and why. This is even true when it comes to estimation tasks.
- daze42 7y ago
  This seems accurate to me. Maybe the parent is speaking from a place in the Valley of Despair on the Dunning-Kruger curve. The good news is, they're just passing through.

prometheus76 7y ago

The other problem with estimates of time with regard to certain tasks is the pareto principle. Specifically, if I give it to this developer, it will take two days. If I give it to that developer, it will take two weeks. So, how long will it take?

hnick 7y ago
Problem is, if you always give it to the two-day developer your two-week developer might miss out on chances to improve. One place I worked just billed the client what we would as the reasonable rate and tracked the rest as training. I guess pair programming is one approach to get around this, you'd probably consume a week of dev time total in your example but it's better than two.

DannyB2 7y ago

> Accurate, precise estimates are more expensive than the actual task itself. That! That is is. You CAN get accurate estimates. But the cost of doing so is infeasible for any significant project. You can break things down into smaller pieces, easier to estimate. But the bigger the overall complexity, the more small pieces you will miss or fail to see. Or fail to see how parts interact. Or fail to recognize how far the influence of some element may reach. And other reasons estimates turn out wrong. The difficulty of software estimation was recognized in the 1960's. Again in the 1980s during the microcomputer revolution. And again sometimes more recently. When even the biggest companies, with vast resources, and billions of dollars cannot estimate when their product will be ready, how is a small software team expected to precisely do so. There was a joke of which year Windows 95 would ship in. At the same time, a business needs some kind of timetable because many other things need to coordinate with the completion of a software project. Maybe recognize the best you can do is have an idea of how well things are going. As a project gets further along you get a better idea of when it will be complete -- especially when there are lots of unknowns. When constructing a building, there are lots of knowns. How many square feet. How many walls. Electrical outlets. Plumbing fixtures. Etc, etc. They can give you a very good estimate. It's all things they've done before. Software is generally things that you've not done before. (or you may suffer the second system effect if it is)

sbarre 7y ago
After doing this for 25 years, I always say "you never get good at estimating, you just get less shitty at it".. Lots of people don't like that statement, but I stand by it.. I eventually stopped trying to estimate time required to deliver a specific thing, and instead started working backwards and seeing what can be done in the time we have. It's still estimating, but it's somehow a bit easier, especially if you're willing/able to re-evaluate along the way. I know that's basically Agile but I removed all the ritualistic BS. ;-)
- DannyB2 7y ago
  After almost 40 years of doing this, I can agree that you do get better at it. But perfection never seems to materialize. Even if I get better at it, a lot of my younger coworkers do not. So the phenomena seems to continue.

hnick 7y ago

I've seen a corollary in my work with legacy system migrations and technical debt. Often scoping the work and taking so much care to not cause any issues grinds the work to a halt. We could do well with taking a bit more of a risk&fix attitude (after all, leaving it as it is constitutes a BIG risk over an infinite time frame).