[bgribble]

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well.

They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engineering team for not delivering to their estimate.

[pocketarc]

I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go shopping around and may end up signing with someone else.

Having a promised date lets you keep the opportunity going and in some cases can even let you sign them there and then - you sign them under the condition that feature X will be in the app by date Y. That's waaaay better for business, even if it's tougher for engineers.

[loloquwowndueo]

“Sign up and pay at least part of it now and we’ll prioritize the feature”.

I’ve seen enough instances of work being done for a specific customer that doesn’t then result in the customer signing up (or - once they see they can postpone signing the big contract by continuing to ask for “just one more crucial feature”, they continue to do so) to ever fall for this again.

[ravloony]

Just to consider the opposite viewpoint, I sometimes wonder if it's not better that they do churn in that case. Assuming the sales team is doing their job properly, there are other prospects who may not need that feature, and not ramming the feature in under time constraints will lead to a much better product. Eventually, their feature will be built, and it will have taken the time that it needed, so they'll probably churn back anyway, because the product from the vendor they did get to ram their feature in is probably not very good.

[devsda]

Unless its the first time they are hearing about it, when a customer asks about a feature, sales should've done their homework and checked with the team doing the work to get a rough estimate instead of pulling a number out of their behinds.

[xyzzy123]

The top down push for timelines is because:

In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects.

I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought about and carefully accounted for, BUT in the specific case where it's their own days of effort, those don't feel like money.

Also, the software itself presumably has some impact or outcome and quite often dates can matter for that. Especially if there are external commitments.

[mactavish88]

The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.

1. Think about what product/system you want built.

2. Think about how much you're willing to invest to get it (time and money).

3. Cap your time and money spend based on (2).

4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.

If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.

[pluralmonad]

Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.

[Nextgrid]

I bet if SWEs were seeing anywhere near that 1.5k per day they’d be more inclined to pay attention.

But when you get paid less than half that it doesn’t feel like a problem to worry about. At 300/day of take-home pay, one more day here or there really isn’t going to make a difference.

[the_af]

I think this is unfair to sales.

I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise.

When will you recover from your injury so you can play the world cup?

When will this product arrive that I need for my child's birthday?

When will my car be repaired, that I need for a trip?

How soon before our competitors can we deliver this feature?

"It'll be done when it's done" is very unsatisfying in a lot or situations, if not downright unacceptable.

[AnimalMuppet]

But it's the reality of engineering. If reality is unacceptable, that's not reality's problem.

But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money.

So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the answer is, badly.

The only way estimates can be real is if the company has done enough things that are like the work in question. Then you can make realistic (rough) estimates of unknown work. But even then, if you assign work that we know how to do to a team that doesn't know how to do it, your estimates are bogus.

[iamflimflam1]

If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy?

If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person?

The no estimates movement has been incredibly damaging for Software Engineering.

[Rotundo]

If work on a house was specified like a typical software project, no builder would even return your call.

"I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".

[narmiouh]

Painting a wall has no “if then else”. You dont need to test to see if the wall has been painted.

I guess a fair analogy would be if the home owner just said “Make my home great and easy to use” by Thanksgiving without too many details, and between now ans thanksgiving refines this vision continuously, like literally changing the color choice half way or after fully painting a wall… then its really hard to commit.

If a home owner has a very specific list of things with no on the job adjustments, then usually you can estimate(most home contract work)

All software requests are somewhere in between former and latter, most often leaning towards the former scenario.

[masterj]

When there are huge unknowns, such as in the case of a remodel where who knows what you might find once the drywall is removed, then yes. I happily worked with a contractor on a basement renovation with no estimate for this exact reason.

If it’s something where they have fewer unknowns and more control and lots of experience building the same thing, then I would expect an estimate: building a deck, re-roofing a house, etc

[tayo42]

For any slightly complicated project on a house the estimate assumes everything goes right, which everyone knows it probably won't. It's just a starting point, not a commitment.

[adrianN]

My experience with contractors is limited, but in all nontrivial cases I recall they took longer than estimated and it ended up costing more.

[geetee]

Most businesses like to pretend change orders don't apply to software.

[bsoles]

Anybody who worked with a local contractor knows that their estimate and the reality has no correlation.

When you ask for a firm estimate, you are basically asking to be lied to, and the contractor happily complies by telling you a lie.

[genghisjahn]

Anyone from a sales roll care to speak to this?

[carefulfungi]

Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.

[mcfly_c-137]

Really interesting topic. (I’m actually somewhere in between sales and dev - doing Req. Engineering, Concepts and planning).

Personally I consider it more important to constantly narrow down any uncertainties over time, than having an initial estimate that holds. The closer it gets to any deadline, the less uncertainty I want (need) to have because the less options remain to react to changes.

And frankly, this usually not only applies to estimates but also to things that these estimates rely upon. The longer the timeline, the more room for circumstances and requirements to change.