[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.

[wreath]

Why do that if your competitor already has it? I'd just go talk to the competitor instead. If you aren't able to ballpark when the feature will be done, why should I trust you will once I pay part of the price?

[loloquwowndueo]

If the competitor already has it why are you talking to me? :)

[stavros]

Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.

[loloquwowndueo]

No, parent said they’d go talk to the competitor. They didn’t say they were already with them. Don’t change the scenario.

[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.

[SpicyLemonZest]

I understand the intuition, but it's a misunderstanding of how software sales operates. There's no tradeoff between prospects who need new features and prospects who don't, because salespeople love that second category and you'll have no problem hiring as many as you need to handle all of them.

[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.

[xyzzy123]

How would you decide between doing project (a) this quarter, or project (b)?

If you cannot (or refuse to) estimate cost or probability of success in a timebox you have no way to figure out ROI.

To rationally allocate money to something, someone has to do the estimate.

[mactavish88]

The exact same way you'd treat any other investment decision.

In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.

You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.

[xyzzy123]

You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).

When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.

[mactavish88]

What you're asking is the equivalent of going to a company whose equity you've bought and asking them: what's the price going to be in 6 months' time?

[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.

[xyzzy123]

Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point.

I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable.

I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct.

Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...

[tuna74]

How much plumbing knowledge do you have?

[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.

[the_af]

I don't know that it's the reality of engineering. (Edit: in fact there are some comments for this post providing counterexamples, an interesting one is the hardware world).

It's what we software engineers like to tell ourselves because it cuts us slack and shifts the blame to others for budget and time overruns. But maybe it's also our fault and we can do better?

And the usual argument of "it's not like physical engineering, software is about always building something new" because that's only true for a minority of projects. Most projects that fail or overrun their limits are pretty vanilla, minor variations of existing stuff. Sometimes just deploying a packaged software with minor tweaks for your company (and you must know this often tends to fail or overrun deadlines, amazingly).

I know another "engineering" area where overruns are unacceptable to me and I don't cut people slack (in the sense it's me who complains): home building/renovation contractors. I know I'm infuriated whenever they pull deadlines out of their asses, and then never meet them for no clear reason. I know I'm upset when they stumble over the slightest setbacks, and they always fail to plan for them (e.g. "we didn't expect this pipe to run through here", even though they've done countless renovations... everything is always a surprise to them). I know I'm infuriated when they adopt the attitude of "it'll be done when it's done" (though usually they simply lie about upfront deadlines/budgets).

Maybe that's how others see us from outside software engineering. We always blame others, we never give realistic deadlines, we always act surprised with setbacks.

[Nextgrid]

> maybe it's also our fault and we can do better?

Part of it is absolutely our fault; part of it is the industry.

In the electronics world, when you need <common functionality>, you can find an off-the-shelf part that fits your requirements, fit that part in and it'll work. When you need logic in a hardware device, nobody's rolling their own CPU from discrete parts - they just take the cheapest microcontroller fitting the requirements.

In the software world we don't seem to have this concept of building blocks for common functionality even decades into the industry. Most software projects are some flavor of CRUD app with custom logic operating on the CRUDed objects. You'd think all the complexity would be in the custom logic, but actually it's at best 50-50 and at worst most of the complexity is in the whole CRUD bullshit and not what happens to the object once it's CRUD'ed.

How come in 2026 there's still no way to have an off-the-shelf component I can buy to do "I have a table of objects on the server, and I want to expose this as a UI to the client"? Why do I still see people writing this by hand in React/$JS-framework-of-the-day and messing around with things like OpenAPI and/or writing serializers/deserializers by hand? I swear most of the work I see in the web development space is the minutia between client/server communication.

I think there are several reasons:

* overengineering/resume-driven-development: even if there was to be an off-the-shelf component to do the task, people would probably avoid it and prefer to bullshit around reimplementing a (worse) solution. That's already the case where people are using React/SPAs/etc for views that do no need any interactivity and could just be an HTML form.

* political choices influencing tech selection: more often than not some tech or service provider is selected based on political reasons and not technical, and then the engineering challenge becomes as to how to shoehorn this ill-fitting part into our solution.

* aversion to paid software: hardware engineers are expected and allowed to select parts that cost money. I've never been on a software project where we had an explicit budget for licensing software. Reaching for paid software became the least resort option I'd have to fight for and burn political points, while spending 10x the cost building a (shittier) replica in-house was considered fine.

Due to the last point there's also little incentive for software providers to build and sell such components, so the market is quite small and not competitive, with the (very few) competitors having their own dealbreakers. Firebase will give you the instant database and UI, but then you're forever tied to paying them rent. You can't just license the server component and install it in-house like you can buy an FPGA.

[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".

[moregrist]

Sure, for roofing jobs or other large repairs, that’s true. But for remodeling it’s pretty different.

When I’ve engaged with a contractor for remodeling, I usually have some vague idea like “we should do something about this porch and deck and we’d like it to look nice.”

The contractor then talks to you about _requirements_, _options_, and _costs_. They then charges for architectural plans and the option to proceed with a budget and rough timeline.

Then they discover problems (perhaps “legacy construction”) and the scope creeps a bit.

And often the timeline slips by weeks or months for no discernible reason.

Which sounds exactly like a lot of software projects. But half of your house is torn up so you can’t easily cut scope.

[iamflimflam1]

But the correct response to that is not - "I'm not going to tell you how long that will take" it's "let's work out what you are trying to accomplish".

Though the "I'm replacing your crew every three days" does cut a little too close the bone...

[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.

[iamflimflam1]

Building a house, adding an extension, replacing a bathroom, building a deck. Many unknowns - you'd still expect an estimate.

[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.

[iamflimflam1]

Definitely so. Most business people that I've worked with do understand that. And provided problems are communicated early enough can manage expectations.

Where I've seen issues is when there is a big disconnect and they don't hear about problems until it's way too late.

[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.

[tuna74]

Then you need a new estimate. That is not hard to comprehend.

[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.

[patrick451]

These are just bad contractors. I used to work for a remodeling company. We came in under time on the vast majority of projects because the guy who ran the company knew what he was doing and built slack into the schedule.

[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.

[genghisjahn]

Are you in sales or have you ever worked in sales?

[carefulfungi]

I've been a CTO (with a lot of pre-sales engineering responsibilities) and a VPE responsible for engineering - sales relationships; I've participated in hundreds of prospecting and customer calls and many years of sales planning/strategy/deal review meetings. I can tell you from first hand experience that sales (and marketing, to a large extent) are both strictly measured and held accountable to forecasts. Forecasting a buyer's behavior, or a lead gen pipeline, or deal timing is not easier than forecasting the construction of a new feature.

[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.