Hacker News Reader

In my experience, PM's or whoever usually want estimates on the spot. They want estimates fast, but then they treat them as though they were well researched. If you tell them "there's a 75% probability we can get it done in 2 months" they hear "we can get it done in 2 months".

There's also a tendency to leave out important information. I recently worked on a project where 1) more than half of the features were not in the requirements because the product manager assumed we could re-use existing functionality from a completely separate application (we couldn't); 2) half of the requirements from the new work were left out of requirements because they didn't bother to specify them; 3) a critical requirement regarding how data was to be aggregated in search results (which is the primary feature) was not included because the architect didn't bother to tell anybody about it except for a passing "hey, what if we did this instead" before going on vacation. This caused 2 weeks of re-work after we were done, that would have taken 2 days if we did it from the start.

Our engineering team reviews all requirements as a team before giving estimates and this STILL happened, because we couldn't know what was missing. Good estimates begin with good requirements, and usually the people responsible for those do not end up being accountable, it ALWAYS falls on engineering.

That serial approach (get good requirements; design and code; test) always works that way. An iterative approach can work better. Why isn't the architect in standup at least during the beginning of the project? All this could have been shortcut.

Because developers want to be left alone and also because they think meetings are unnecessary

The conversion of estimates into commitments isn't some exception to the rule, it is the rule which is why only fools give the business estimates for things.

Also ...

Do we really think that every project is such a unique snowflake that we can't build models?

Well, yes. That's inherent to what we do. Every project IS a special snowflake. If it wasn't we'd just download the software and install it. Oddly enough, installing and configuring software that is pre-made is very predictable and such projects rarely overrun. The sort of projects we're talking about are where pre-existing software won't do and thus, by definition, what you need is something special.

Exactly. It's hilarious to imagine management coming to a dev with a problem and a set of objectives and the dev replying mockingly "What are we some kind of special snowflake that we have to satisfy a different set of requirements than an off-the-shelf solution can satisfy?".

Every structure and bridge and road and tunnel project is obviously unique also. Unique terrain, unique architecture, unique engineering. If the idea is to look to other engineering to improve this, again, it's not like software is some kind of special.

They're only unique in trivial ways. Roads are made of the same material everywhere - they're different only in some strict geometric sense.

Meanwhile even very ambitious tunnelling projects like the Gotthard Base Tunnel, if you watch documentaries about them, they only hit a very small number of really unexpected issues even over long periods of time. Tunnelling is an incredibly predictable business. You buy some TBMs, set them going and worst case, you hit unexpected rock types or have an unexpected malfunction. The technology is advanced but rock is the same as rock has always been. Once the project planning is over requirements don't change. The course you're on doesn't change. Workers are largely trainable and replaceable - you never find you're unexpectedly relying on some random worker somewhere deep in the org chart who is 50x more skilled than their coworkers and who just got poached by a company that pays 3x as much as you can. The users/customers have no input: they get what you deliver and a tunnel is such a simple thing talking about whether they like it or not is a nonsensical question - it's a tunnel.

> They're only unique in trivial ways. Roads are made of the same material everywhere - they're different only in some strict geometric sense.

That's about as accurate as saying that software projects are only unique in trivial ways because there's probably already a free library or plugin that can do whatever else you need. It's easy to assume your occupation is much harder than everyone else's but we rarely have deep knowledge of the challenges other people face day to day outside of our own line of work.

As a simplified example, the design of a road, its pavement layers and its foundation is determined by factors like traffic loading characteristics, service requirements (peak capacity), speed limits and visibility, ground conditions, climate and more (see Caltrans' Highway Design Manual at http://www.dot.ca.gov/design/manuals/hdm.html), many of which rely on professionals in entirely other fields.

As kaspy points out in his, this is just more software engineering hubris playing out. I took architectural drafting classes in high school, and there are tons of technical differences and considerations that go into building design. And I was only dealing with drawing them, forget about having to have all that in my head and actually being able to make decisions on it.

To make what I hope is an apt analogy back to software, you are basically saying, "Oh, their job is easy. All they have to do is follow established design patterns!" But, of course, we also have design patterns... Why don't we say the same thing about ourselves? Because we know that that's complete bullshit; there's a lot of thought and wisdom that goes into actually building stuff around those patterns.

Yes, but architecture isn't the same thing as road building where the same small set of variables play out repeatedly over centuries. The work an architect does is much closer to the work software engineers do.

> How many engineers are doing things like using real numbers from previous work to build models before estimating?

Fogbugz created a feature called Evidence-based Scheduling (http://help.fogcreek.com/7676/evidence-based-scheduling-ebs). It's probably the only real quantitative approach that I have seen while working on web development projects. I'm probably wrong to assume that more "technical" fields like aerospace do much, much more than this, but it was really interesting to use this with what was mostly CRUD-work.

EDIT: added link.

> Previous work shows we can handle a project of this size in 6 months 85% of the time

More like: Previous work shoes that this project should take between one week and eighteen months at a 95% confidence interval.

...there aren't many projects one can do 300 times to narrow that window. And asking for a date instead of a confidence interval is asking for an ambiguous estimate in the first place.

Another tenet is that work is work. You attempt to break the work into chunks that are close enough to previous work efforts to use your model. If you can't do that, then you don't actually have any idea of what you're doing yet. Which is fine, but you certainly can't estimate in that state.

Is this how you/your team/your company work? Do you know of any resources you would recommend for those of us who are interested in learning more?

This is generally part of the "No Estimates" movement. I learned about it from an internal talk, but I will ask the speaker if he has any resources I can point you to.

We are not there yet, but are moving in that direction. We weren't previously even collecting the metrics required to create models in the first place, so we didn't have any data.