[bluGill]

> Trim features, push date, bring in extra help, or crunch.

There are problems with all of these. The company knows they can sell X of the product for $Y (often X is a bad guess, but sometimes it has statistical range - I'll ignore this for space reasons but it is important!). X times Y equals gross profit. If the total costs to make the feature are too high the whole shouldn't be done.

If you trim features - the affects either the number you can sell, or the price you can sell for (sometimes both).

If you push the date that also affects things - some will buy from a competitor (if possible - and the later date makes it more likely the competitors releases with that feature).

Bring in extra help means the total costs goes up. And worse if you bring them in too late that will slow down the delivery.

Crunch is easiest - but that burns out your people and so is often a bad answer long term.

This is why COMPANIES NEED ACCURATE ESTIMATES. They are not optional to running a company. That they are impossible does not change the need. We pretend they are possible because you cannot run a company without - and mostly we get by. However they are a fundamental requirement.

[praptak]

If your business model needs the impossible then it's a bad business model. If your margins are too thin to absorb the schedule uncertainty then don't produce software.

Alternatively treat it like a bet and accept it may not pay off, just like any other business where uncertainty is the norm (movies, books, music).

[moregrist]

> This is why COMPANIES NEED ACCURATE ESTIMATES. They are not optional to running a company.

Sure, but even accurate estimates are only accurate as long as the assumptions hold.

Market conditions change, emergency requests happen, people leave, vendor promises turn out to be less than accurate.

And most estimates for non-routine work involve some amount of risk (R&D risk, customer risk, etc.).

So pounding the table and insisting on ACCURATE ESTIMATES without a realistic backup plan isn’t good business, it’s just pushing the blame onto the SWE team when (not if) something goes south.

[Phlebsy]

I would settle for accurate estimates being a requirement if sticking to the estimate and allocations is as well. Every project I've been a part of that has run over on timeline or budget had somebody needling away at resources or scope in some way. If you need accuracy to be viable, then the organization cannot undermine the things that make it possible to stay on track.

[kakacik]

Also, if you need accuracy stay away from questionable vendors of 3rd party products, as much as possible since they are chaos generators on any project involved.

In my work we have our core banking system designed in 80s on top of Oracle DB so everything is just boxes around it, with corresponding flexibility towards modern development methodologies. The complexity of just doing a trimmed copy of production servers for say user acceptance test phase is quite something, connecting and syncing to hundreds of internal systems.

Needless to say estimates vs reality have been swinging wildly in all directions since forever. The processes, red tape, regulations and politics are consistently extreme so from software dev perspective its a very lengthy process while actual code changes take absolutely tiny time in whole project.

[nightski]

Companies need accurate estimates like I need accurate stock market forecasts.

[jungturk]

They don't NEED them, but better project estimates can reduce the error bars on other dependent estimates (e.g. estimated sales, estimated ship dates, estimated staffing requirements, etc...), and that might be useful to a business (or not).