I have an intern writing and app for internal use. He's using Python, tkinter, and one pip-install package for talking on modbus. Deployment to our hand full of users is easy. Low number of dependencies. It's going really well. A few days ago he said "I really would have liked to use ZZYXX-web-whatever for the GUI instead of tkinter". I said "you users don't give a fuck about that but keeping dependencies easy to manage is important". Users don't actually care about dependencies either, but they do care when it negatively affects getting the thing up and running (or slows development or...). His main gripe with tkinter was actually a lack of familiarity. I said "dude, a large part of your job is going to be learning. Get used to it."
Many architectural decisions in software are completely arbitrary and don't matter nearly as much as some people think. That's not to say all such decisions, but really a lot are not a big deal. In those cases KISS trumps most preferences and big ideas. IMHO of course.
Thanks for this, this prompted me to submit an article I read yesterday. Pilots don't need the debate because the work is (for the most part) well-known. There is no debate because the aircraft has a method of working that is well-understood so long as you aren't in the field of flight testing new aircraft, which is to say: the vast majority of pilots. As a consequence, there is zero need for discussion because there is "one way" to do things, and where there are choices (actions that can be done in any order) there are often conventions (such as going left-to-right across a panel to reduce the risk of missing a step).
Software is different. Software is design, which pushes it towards the need to communicate more often and work in a collaborative fashion. In fact, a lack of communication seems to be the problem in the org of the article and not the desire for high quality software. The programmers weren't talking with each other or their customer and instead acted more like the pilot situation, but without sufficient insight to actually make decisions or take the actions they were taking.
The fact that attention to code doesn't prevent all problems doesn't mean that it doesn't prevent some problems.
Imagine if pilots spent an hour debating which sequence to push a particular set of buttons that would be needed after takeoff - where either of several ways would work - to the point that the plane took off hours too late.