Remy Dyer said:
Boeing 737 Max. MCAS qualifies I think: literally forced two planes straight into the ground. Broken sensor.
In all of these cases, a designer / programmer is being too clever: making design choices because they think they know best.
Wiser programmers stick to “Keep It Simple & Stupid” for a reason.
Having thought about this a little longer: I think I've done a disservice to many junior programmers. The ones who are actually doing the work.
What's most likely, is that said programmers realized there would be an issue, and probably just set about following the obvious train of logic and the requirements necessary to fix it, when their boss noticed, and forbade them 'wasting time', because 'that will never happen'.
If you're the junior programmer, I'd like to recommend you read Chris Voss's works on negotiation, because guess what? It's not your bosses reputation on the line here, it's your reputation and future career, and you have in fact in the right to follow the 'obviously this is the only correct thing to do' logic. Your boss doesn't care because he's a lot closer to retirement, and probably he already leaves all the actual programming, ie, the work, to you anyway.
My advice then is to care, and not let this sort of thing through, but do so as sensibly as you can. You'll need to be a good negotiator, and you'll need to arrive at a solution that honestly makes everyone happier. Maybe point out how this is an advantage, and will create market differentiation (good if he uses the 'it's ok because no-one else does' excuse).
Either way, not doing anything, or just sticking your head down and failing to fix the problem - all of these are fails, that may haunt you. It's not always easy to figure out what is necessary and what is not - be aware that it's all too easy to become invested in your own work, because it's your own work.
The litmus test is whether the failure more you are concerned about is 'reasonably foreseeable'.
If it's something you have evidence of, however oblique, then it does meet that test. Preferably bring up such a case your boss knows of, and give him a 'searching for a no' question. (one he'll say 'No' to, like 'do you want us to look like fools?' or some-such. Saying no will make him feel in control. For other great little nuggets of wisdom - again, Chris Voss).
From there you want to note that this is really just a 'little thing' of the kind that when taken care of, will ensure that the 'big things' fall neatly into place. Also note the 'devil is in the details' and details like this one is what separates the good from the trash. Try to sell it as what it really is: An opportunity to improve.
The whole KISS thing isn't wrong, but making allowances for such as 'what if it needs to reboot in flight' are actually things you DO need to chase down and do something about. Robustness is the expectation, and you'd better meet it.
For the battery pack, it could have gone down something like this: (PFY is the guy doing the work, PHB is the pointy-haired-boss in charge. Yes, it really is just like Dilbert).
PFY:'Boss, we need a more accurate chip so we can detect if someone's charging their hearing-aids".
PHB: Don't worry about it, it'll blow our parts budget. We'd need it to work down to 0.1% current and that's not reasonably cheap. Our competitors don't bother, and we have to be competitive, so we don't need to fix this.
PFY: 'Oh, ok'.
In this specific case, the PFY could have even realized that there was a cheap solution available that would work in all cases - but it would take a little more prototyping time to figure it out, which the boss would have vetoed as 'a waste of time'.
The problem isn't dumb engineers/programmers, it's bosses who think they have everything figured out, but who no longer actually do real technical work any more.
They push papers, remember how quick and easy all that technical work once was (never remembering the long hours that they were so busy their brains couldn't even note that time was passing) and feel like the new generation is slow and stupid, and won't to pursue flights of fancy and other yak-shaving exercises.
Thus they feel like the timelines they estimate all work should be completed by are perfectly accurate, even though they are always unrealistically optimistic - and try to force everyone to keep up with their broken expectations. So the poor guy doing the actual work, is probably trying to fix things just having discovered this new issue, and is already probably running deep 'behind schedule'.
The only solution for all of the above? If you are the guy actually doing the work, and your boss isn't listening, you need to learn better negotiation skills. Don't 'look up' to your boss for their negotiation skills, because in this situation, it's clear they have actually atrophied away from disuse, being that they're in a position of power. Although honestly, they were probably equally bad when younger: It's just that now they have authority. so they no longer need to get any better.
There's no easy solution - we all face situations where the room is against us, where we have something unpopular to say, and where we don't have the authority to just 'have our way'. But it turns out, you don't actually need that authority, you just have to learn how to get about without it.
