Then ignoring the existence of the weaker memory model of ARM (versus the stronger x86/x64) is even stranger. And even if x86/x64 models are stronger, they still need some fences and using them all the time would be too slow. So I still don't really understand the arguments of the article.
The article does not ignore architectures like ARM. You do need fences, but not all the time - the compiler can avoid fences in places where there is no danger of violating sequential consistency (e.g. on accesses to provably local objects).
Here's an addition to the answers from the others -- I'm one of the authors of the post.
Thanks for your feedback.
Perhaps we did not sufficiently emphasize it in the blog post, but we do tell the students about strong existing architectures, open source as well as from industry. The books listed in further reading in the post actually contain chapters about git and emacs, and I share your enthusiasm for Bentley's little language approach.
The philosophy of the course is based on trying to apply published approaches to software architecture (such as those in Rozanski & Woods' book, but it could be others) to real systems actually maintained and used. We encourage to get in touch with the creators of those systems.
The students actually take a deep dive into a foreign code base -- I included pictures because that is easy to share in a post, but the students analyze code, report about that, execute test cases, deploy systems, etc. The pictures are indeed, as suggested by some of the others, means for communication.
What repels me is the kind of approach taken by this Rozanski & Woods book. It's like a 500 pages of authors philosophy of software, and whether all that is of any use is completely uncertain. There is not much of a widely established corpus of knowledge on software engineering/architecture, another book would treat an almost completely different set of concepts, and whatever is commonly agreed upon is trivial and most people invent in on their own when they need it. You can publish completely anything about "Software architecture" in this spirit thats sounds smart enough and it won't ever be put to any test. I personally, from experience, don't believe any practical high-level theory of software engineering of this kind exists at all, the more "philosophical" or "theoretical" it gets the less useful it becomes. It is much better to spend this time studying established disciplines where things actually get tested out one way or another, mathematics, algorithms, operating systems, ... If there is anything specific to be taught under "software architecture", it's those ideas ("patterns") that made certain programs so much better than the alternatives, but you only really learn them by digging deep in, not by studying some very abstract models.
From your post it seems you think software architecture and -engineering are the same.. In this course -- disclaimer: I was a student taking this course -- it's not that case, Software Architecture is not the sum of a program's lines or modules. SA is the methodology of getting involved and steering a project, this includes handling team efforts and other stakeholders. Looking and learning a lot of (implementation) patterns is of course very useful, but only a subpart of SA.
I tend to think that a good SArchitect knows that the patterns they might be using are good or well suited for the current problem, a better SArchitect knows that he's perhaps using a less well suited pattern for the problem, but can layout a plan to migrate to a new and better situation without breaking continuity of the project.
Furthermore, it can't be stated clearer that in the course there are a lot of guest lecturers who _do_ show different idea's.
We advised the students to look critically at recent open (or just closed) issues and pull requests, as well as e.g., the mailing list for the project at hand. Based on that they could get a feeling what was happening at the moment, and what a typical contribution looks like.
If you want to contribute code, we found that it works best if you work on parts of the code that are currently under active development. This also means that you do not have to have a deep understanding of the full code base: A broad overview suffices.
Some of our students also offered documentation for, e.g., installation or deployment: they struggled themselves, and offered what they learned back to the project.
The incorrect 1998 was derived automatically by HN from the ACM classification in the pdf it seems.