I know this is a common sentiment, but I don't quite get it. Engineering is often about optimizing multivariate functions, and cost is just another variable to optimize. If you frame it properly to engineers, they can solve cost problems too.
"Good, cheap, fast: pick two" is a law of the universe that most engineers deeply understand, and good devs will produce the best product they can according to which two are chosen.
You know what’s cooler than an expensive thing? A high quality thing with higher margins. A very well known and highly profitable company has taken that model pretty far (like trillions in valuation far).
Engineers arent really responsible for these types of attitudes though. Management are. By and large engineers will do as they are requested.
I find it far more plausible that costs ballooned due to an empire building dynamic by management than because engineers arm twisted them into building something "cool". Same reason Uber has, like, 150 people working on a mobile app.
Engineering is all about fitting within your constraints. Make budget one of those limits and life will uh find a way.
Well sure, you literally just removed the cost optimization variable. SpaceX vs. NASA is a clear example demonstrating that engineers can do this sort of optimization when it's given to them as a constraint. NASA's rocket designs were all custom, single-use, often down to the bolts because the budget was per-project/launch, where SpaceX rockets were designed for reuse and cost minimization across multiple launches.
In eng school there was a saying: An engineer is someone who can build something for $4 that any fool can build for $7.
It's obviously possible, SpaceX vs. NASA is an existence proof. Maybe you have something specific in mind when you say "technical engineering optimization problem", like a formula you can minimize mathematically to account for every little contribution, but this often isn't necessary. Like when solving physics problems using approximations, you often only need to minimize the first and second order largest contributors to the cost and you'll be in the right ballpark.
This also means you don't need to find the literally absolute minimum and capture literally all of the contributors to the cost during the design process. And of course this is what happens in the real world already, do you think accountants and pointy haired bosses guiding a bunch of engineers are going to find the absolute minimum? Of course not, they find what looks like a minimum from their limited view of a project after the engineers estimate the costs of producing parts and the labour required. Just close the loop without the accountants and bosses and engineers can do this optimization themselves.
I disagree that I was making this point. I said it currently involves accountants and bosses, and I'm saying it doesn't have to because you can make it an engineering problem. The accountants and bosses don't have any unique skills or insight here that aren't in principle also accessible to the engineers.
These are mostly hacks to get around the fact that the engineers haven't been given enough information. If you just say, "we need product X that can be produced at cost Y/unit and we need to start production by date Z", then this is a satisfiability problem that the right set of engineers can evaluate as possible or not possible. It's fine to assign a team lead with the requisite experience and authority to pull in the engineers, equipment and data they need to answer this question, but then you get out of the way.
Answering this question involves laying out a semi-detailed plan for how to achieve the goal. If it turns out to not be possible within the given constraints, then you at least have that plan to inform you where the expected cost or time overruns are (or the unknowns/uncertainty), and whether that means you have to revise the expected selling price, deadline or you can compromise on the scope to achieve the desired selling price.
I will agree that some engineers and programmers really don't care about this stuff, but I'd argue it's because it's typically not part of their job, and sometimes because worrying about costs and schedules is not an "interesting problem". But it is an interesting problem if you frame it as set of optimization and satisfiability problems.