Ask HN: How do you do estimates in 2021?

> And what do estimates provide here, that sales just picking a number doesn't?

Example #1:

  - a company in the industry asks your company to implement $FOO, they want to know how much it'd cost
  - the sales people talk to the engineers, who come up with a certain amount of time it could take
  - the sales people turn this into a monetary figure of $X
  - a contract is made, the project proceeds to be developed, probably with some delays and overruns, but works in the end and is profitable

Example #2:

  - a different company in the industry asks your company to implement $BAR, they want to know how much it'd cost
  - the sales people decide that $BAR is similar enough to $FOO and that there's no need to consult the engineers, they just give a similar estimate
  - turns out that the project MUST be made for JavaEE, since that's what the company is using
  - turns out that the project MUST work on Java 8, since that's what the company is using
  - turns out that the project MUST use Oracle DB, which then requires licensing and particular setup for the environments
  - turns out that the project MUST use GlassFish and instructions must be written for it, because deployments will be done by the clients' Ops person
  - turns out that the project MUST be deployed as a .war file, because of the above
  - turns out that the project MUST work in RHEL 7 because that's what the clients are using, same situation as with Oracle
  - turns out that the project MUST have both a test coverage of >80% and integration tests, which weren't a consideration in the previous project
  - turns out that the project MUST support IE because for some reason that's what the employees of the client company are using
  - as a consequence, the technical implementation takes about 200-300% longer than previously estimated
  - the project is no longer profitable and is a net loss for the company

Example #3:

  - there's yet another company that asks for $BAZ, they want to know how much it'd cost
  - the sales people had a really bad time with that last project, so this time they decide to increase the estimate
  - turns out that this new project does not have any of those constraints
  - because of this, the estimate is really large
  - the company looks at this and decides to go with your competitor instead
  - your company loses out on the opportunity of working on the project entirely

In the example #1, the ballpark figures were accurate enough for the project to be done in a profitable manner. In example #2, there were factors that weren't considered and would result in either contractual penalties, the clients deciding to break the contract because you can't deliver on time, or to take you to court. In example #3, past data was used in an inaccurate way due to not being applicable to the constraints at hand (or lack thereof).

Of course, the above happens when you're in a market that requires estimates as a part of BOMs, which is a lot like bidding on projects and is just a race to the bottom for the most part.

Yes thank you so much for that good catch. Much obliged!

> Why does the size of the work that needs to get done matter? If you need it you need it.

Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract, and you could only apply for the contract until a specific date. The value of this feature outside this scope was pretty much zero.

I would prefer not to estimate at all because estimates are, in the Lean sense, waste: i.e., something that your customers don’t value.

Unfortunately, that argument never worked with my managers at project budgeting time.

As a result, because I was really bad at estimating, I spent a day teaching myself function point (FP) estimation. I also found a chart detailing how many hours of effort an “average” organization required to build projects of varying FP sizes. This meant that it was easy to make a simple spreadsheet using the chart data and Excel’s FORECAST function to generate estimates.

With that approach, my subsequent projects were always within 10% of the estimate, which is much better than my pre-function-point estimates. Combining that approach with the Agile idea of working on the most important features first meant that my projects were largely free of drama come deadline time.

So 4 months is 8 quarters or 8 years?