[naasking]

> you basically make the same point as wanted to make: you can’t just frame it as an engineering problem, it involves accountants and bosses.

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.

[ks1723]

Ok, then I misunderstood, and we can only agree to disagree. I think there need to be people caring about organizational stuff which you cannot fully formulate as engineering problem: setting deadlines, putting teams together, determining team leads, determining how much budget is spent on which branch or discipline or even which part development. In addition, even more technical problems like calculating and comparing costs resulting from parts-Design over the full product lifecycle (design, manufacturing, usability, maintenance, repair, disposal) is not feasible today. And using approximations amounts to making assumption and thereby decisions up-front, where you usually cannot oversee all their implications. Designing complex machinery and shaping the organization which builds them is hellishly complex.

[naasking]

> I think there need to be people caring about organizational stuff which you cannot fully formulate as engineering problem: setting deadlines, putting teams together, determining team leads, determining how much budget is spent on which branch or discipline or even which part development.

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.