And who drove the decision to turn the LED on and off with a microcontroller pin: was it the software engineer, hardware engineer or a higher level 'systems' engineer?
Optimally, on smaller projects it ought to be systems architect, experienced in hardware, software, and user interactions design. On larger projects, it better be a tightly knit team of people, whose combined experience covers most of the bases, and who are mature and secure enough to ask others for help at times when the core team is out of its depth.
That month's favourite software methodology designed to predict budgets to within 1% commits the method into the project, anyway. A test plan is drawn up.
If a methodology is not battle-tested by this organization, no way it can predict the budget within 1%. In my experience, 5% is a more realistic goal, with a rock-solid methodology, stable core team, and a familiar technology stack.
I had my own "interesting conversations" with managers who would require "to the cent" estimate. I would ask them how long does it usually take them to get from home to the office. They would invariably give me a range estimate.
Then I would say: OK, you've been driving this road for several years, every weekday, and still you can only predict the time it'll take you with 15% precision. Why is that? What factors affect this? Can we now discuss the similarly operating factors that add variability to our project delivery time?
However, when the prototype is presented to the customer, although they acknowledge that it works they are troubled by a few things.
Which should be fine, if the organization understands that maybe only prototype v6 will be good enough to base a mass market product on. Rapid prototyping tools and methodologies are of great help here. Also, properly randomized, representative, and impartial usability testing.
The problem remains: who understands how to do it all? Possibly no one. And if the methodology assumes that engineers are all 'line-replaceable drop-in resource units', maybe no one is even capable of joining the necessary dots to come up with the above list.
Ah, we're coming to the crux. In his followup book,
https://www.amazon.com/Design-Essays-Computer-Scientist-ebook/dp/B003DKG5H6, Fred Brooks discusses the role of architect, and the perils of his or her too literal subordination to management hierarchy.
Who were Albert Einstein's managers over the years? Can you find out even if you really try? Humanity doesn't seem to care much about these guys, not matter how good managers they actually were.
Likewise, history remembers Ferdinand Porsche and Alec Issigonis, but not necessarily the people who formally managed them at one point or another. Designers / Architects / Artists / Musicians matter all by themselves!
I think this is a trivial example of the same factors that might lead to the Boeing problem or the Challenger disaster.
Too early to tell about Boeing. The smoke screens of personal accountability avoidance are too thick at the moment. It is not unreasonable to assume that there were engineers and managers who were sounding the alarm, and also that they were overruled by the executives. This is a speculation at this time of course.
With Challenger, it is clearer: the managers and executives who were setting the smoke screens back then finally retired or otherwise departed, and a more truthful picture came out, thankfully in time for some of the wrongfully accused engineers to find peace before they die:
https://www.npr.org/sections/thetwo...-engineer-who-warned-of-shuttle-disaster-dies.
I think that the idea of engineers all being replaceable, interchangeable 'resource units' is a fantasy, and that for small projects, rigid methodologies and testing regimes are the stuff of nightmares that increase costs, result in 'clunkiness' and allow potential disasters to drop through the cracks while all the boxes are ticked correctly. The real world isn't compatible with being forced to conform to such rigid, simplistic schemes.
Agreed.
But at the same time, such schemes may be the only practical way to develop massive projects - with massive costs.
The larger the corporation and the more cash-flow-positive it is, the more plausible the 'resource units' approximation appears to be. To the managers, and especially executives, it appears that almost every man in the world is dreaming to work for them, and that they have all the money and stock options they need to entice those who may not inherently want to work to them, but will be - undoubtedly in their minds - be bought for a right price at a right time, if the need arises.
The problem is that too many people who want to work for such corporations aren't interested in, or aren't capable of, creating new things, but are very interested in being paid as much as achievable, for the least amount of work possible, while having their ego constantly stroked by their submissive underlings. In time, such people invade the corporation, or the government agency, and hire more people like them.
Over time, the previously flexible and mostly informal processes that ensured the corporation's past success start struggling to overcome the inertia and "distortions" caused by the people only interested in acquiring money and power. The corporation's "immune system", formerly tuned to identify and push out such freeloaders, is taken over by the freeloaders themselves, and creative people start being pushed out instead.
And then it appears that, in the context of this corporation, the only practical way to develop massive projects is with massive costs, via rigid command-and-control processes. Then, a new corporation, or several, appear. Young, hungry, and agile, they overturn the established conventions, and new corporate cycle begins. Think about it: would Mercedes, or NASA, be able to hire Elon Musk ten years ago, for any money?
To be fair, some very old corporations don't suffer the fate I described. Invariably, they are organized as a looser agglomeration of semi-independent business entities, making their own decisions and bearing responsibility, up to and including dissolution if they fail to produce profits for too long. An oft-cited example is
DuPont, which has existed in various configurations since 1802.