I was reading about NASA's software engineering practices.
When they find a bug, they don't just fix the bug, they fix the engineering process that allowed the bug to occur in the first place.
When they find a bug, they don't just fix the bug, they fix the engineering process that allowed the bug to occur in the first place.
It's true in software, it's true in physical infrastructure (read about the sorry state of most dams).
Until we root cause that process I don't see much progress coming from this direction, on the plus side CS principles are making their way into compilers. We're a long way from C.
Only now is one of those components, the engine, being changed out. And looking at that from this perspective, it's apparently not as humongous a change as many are now claiming: For one thing, it's just one of the four (or more?) parts of the basic recipe; for another, it's not all that new -- electric motors are in wide use elsewhere, and were one of the alternatives in rather wide use in cars, too, before the industry settled on the current recipe ~a hundred years ago.
Anyway, the "beholden to them alone" bit doesn't seem to apply to the automotive industry, since pretty much all manufacturers are in on the switch-to-electrics idea. Which begs the question: Would there really be so much of a customer lock-in in the aeronautic space either? Just like the idea of driving cars by electric motors is unpatentable, what could Boeing (or anyone else) come up with in the basic design of an aeroplane that isn't too general an idea to be protectable, or (most probably) hasn't been tried before?
I think it's part of the reason stocks almost always dip after positive earnings reports. No matter how positive it's always less than idealised.
You might think there's a trick where you can sell maintenance as a new thing but you've just invented the unnecessary rewrite.
To answer your question more directly, once something has been achieved it's safe to assume someone else can achieve it also, so the focus turns to the new thing. Why else would we develop hydrogen or neutron bombs when we already had perfectly good fission ones (they got commoditised).
And security work is rewarded even less!
While I do recognize that this is a pervasive problem, it seems counter-intuitive to me based on the tendency of the human brain to be risk averse.
It raises an interesting question of "why doesn't the risk of security breaches trigger the emotions associated with risk in those making the decision of how much to invest in security?".
Downstream of that is likely "Can we communicate the security risk story in a way that more appropriately triggers the associated risk emotions?"
What's the risk? The stock price will be back up by next week.
Look at the crowdstrike failure as a recent example, but there's plenty more in the past.
Code review is one example of addressing the engineering process, but I also find it very helpful to consider business and political processes as well. Granted, NASA's concerns are very different than that of most companies, but as engineers and consultants, we have leeway to choose where and how to address bugs, beyond just the technical and immediate dev habits.
Soft skills matter hard.
I'm hoping that example holds up, but I'm not well versed in that area so it may be a terrible counter-example but my overarching point is this: overly engineered code often produces less value than quickly executed code. We're not in the business of making computers do things artfully just for the beauty of the rigor and correctness of our systems. We're doing it to make computers do useful thing for humanity.
You may think that spending an extra year perfecting a pace-maker might end up saving lives, but what if more people die in the year before you go to market than would've ended up dying had you launched with something almost perfect, but with potential defects?
Time is expensive in so many more ways than just capital spent.
My argument (and I’m just thought experimenting here) is that without NASA’s rigor, their programmes would have failed. Public support, and thus the market for soace projects, would have dried up before SpaceX was able to “do it faster”.
(Feel free to shoot this down: I wasn’t there and I havn’t read any deep histories of the conpanies. I’m just brainstorming to explore the problem space)
Doing things right takes less time in my experience. You spend a little more time up front to figure out the right way to do something, and a lot of the time that investment pays dividends. The alternative is to just choose the quickest fix every time until eventually your code is so riddled with quick fixes that nobody knows how it works and it's impossible to get anything done.