> It is 2023.
So? Mistakes are still being made, every day. Nothing has changed since the stone age except for our ability - and hopefully willingness - to learn from previous mistakes. If we want to.
> The damage of natural disasters can be mitigated.
You wish.
> When the San Andreas fault goes it'll probably get an entry on that list with a "why did we build so much infrastructure on this thing? Why didn't we prepare more for the inevitable?".
Excellent questions. And in fairness to the people living on the San Andreas fault - and near volcanoes, in hurricane alley and in countries below sea level - we have an uncanny ability to ignore history.
> And this article is throwing out generic all-weather good sounding platitudes which are tangential to the disasters listed.
I see these errors all the time in the software world, I don't care what hook he uses to again bring them to attention but they are probably responsible for a very large fraction of all software problems.
> He drew a comparison between the Challenger disaster and bitrot!
So let's see your article on this subject then that will obviously do a much better job.
> Anyone who thinks that is a profound connection should avoid the role of software architect.
Do you care? It would be better to say that those that fail to be willing to learn from the mistakes of others should avoid the role of software architect because on balance that's where the problems come from. You seem to have a very narrow viewpoint here: that because you don't like the precision or the links that are being made that you can't appreciate the intent and the subject matter. Of course a better article could have been written and of course you are able to dismiss it entirely because of its perceived shortcomings. But that is exactly the attitude that leads to a lot of software problems: the inability to ingest information when it isn't presented in the recipients preferred form. This throws out the baby with the bath water, the authors intent is to educate you and others on the ways in which software systems break and uses something called a narrative hook to serve as a framework. That these won't match 100% is a given. Spurious connection or not, documentation and actual fact creeping out of spec aka the normalization of deviation in disguise is exactly the lesson from the Challenger disaster and if you don't like the wording I'm looking forward to your improved version.
> Challenger was about catastrophic management and safety practices.
That was a small but critical part in the whole, I highly recommend reading the entire report on the subject, it makes for fascinating reading, there are a great many lessons to be learned from this.
https://www.govinfo.gov/content/pkg/GPO-CRPT-99hrpt1016/pdf/...
https://en.wikipedia.org/wiki/Rogers_Commission_Report
And many useful and interesting supporting documents.
> I mean, if we want to learn from Douglas Adams he suggested that we can deduce the nature of all things by studying cupcakes.
That's a complete nonsensical statement. Have you considered that your initial response to the article precludes you from getting any value from it?
> It is not useful to connect random things in other fields to random things in software.
But they are not random things. The normalization of deviation in whatever guise it comes is the root cause of many, many real world incidents, both in software as well as outside of it. You could argue with the wording, but not with the intent or the connection.
> Although I do appreciate the effort the gentleman went to, it is a nice site and the disasters are interesting. Just not relevantly linked to software in a meaningful way.
To you. But they are.
> > We are tied 1:1 to the fate of our star and may well go down with it
> I'm just going to claim that is false and live in the smug comfort that when circumstances someday prove you right neither of us will be around to argue about it.
So, you are effectively saying that you persist in being wrong simply because the timescale works to your advantage?
> And if you can draw lessons from that which apply to practical software development then that is quite impressive.
Well, for starters I would argue that many software developers indeed create work that serves just long enough to hold until they've left the company and that that attitude is an excellent thing to lose and a valuable lesson to draw from this discussion.