Most of the architectural wankery that happens in the real world does nothing to improve security or reliability of a project, though. People love to spend time discussing how to organize the code for potential future maintenance that then becomes irrelevant when requirements change, and didn't prevent someone from missing security vulnerabilities in an outdated version of a third party library anyway. So it's hard to compare that to pilots following a checklist or workers wearing helmets.

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.

The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that.

>> The pilots aren't inventing anything on each flight. If they fly the airplane exactly the same way every time, that's a good thing. Writing new programs is not like that.

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.

Just when I'd lost all hope for the future... Thank you!

> 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.

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.

I wouldn't expect the pilots to spend an hour debating before every takeoff, but rather to have had that debate ahead of time and have a solid set of patterns that they follow so they don't have to reinvent the wheel each time.

The fact that attention to code doesn't prevent all problems doesn't mean that it doesn't prevent some problems.

Most programming tasks don't involve the life safety issues you are using as examples.

It is certainly true that overdesign up front can be fatal to the finances of a project. There is even a term for people who engage in this, "architecture astronauts"

The point is to know what you are working on, and what the customer needs. If they need one or two simple data stores and a couple of web pages, you don't need to spend weeks talking about it.

It's funny because the article starts with a series of factors that the author claims to reduce code quality, and then goes to conclude that the project suffers from excess of quality.

And then ends it claiming that quality is something that slows down development...

Electricity, building houses is based on hard science, code quality is base on opinion

Those guys had to have unions to fight for safety practices. It's to protect the workers. This code quality stuff is about various competing business objectives and now annoying stuff is.

I've never seen a programmer be dismembered from a missing test though I'm sure such things happen in embedded systems and robotics. Tesla Autopilot or the Uber self-driving accident in Arizona are great examples of programming leading to deaths.

I guess if your Uber app doesn't work in the rain that is bad. It's when people are making safety critical decisions that this stuff matters more.

RAM and CPU usage is not an opinion.

Of course it is. You can prioritize cpu or ram or disk or network or developer or user resoures for the sake of the others in countless mixes and for countless mixes of reasons.