The overall idea of using your type system to enforce invariants is called typeful programming [1]. The first few sentences of that paper are:
"There exists an identifiable programming style based on the widespread use of type information handled through mechanical typechecking techniques. This typeful programming style is in a sense independent of the language it is embedded in; it adapts equally well to functional, imperative, object-oriented, and algebraic programming, and it is not incompatible with relational and concurrent programming."
Some folks read Peter Naur's Programming as Theory Building [1] and become zealots. I'm that kind of person. His ideas are woven through my recent talks [2]. Via years of essays, I've been building to a vision of how to build software that I'm calling Continuous Design that's partly stitched together in this overview [3].
> Better when you have experiences to relate back with.
100% this. I've been teaching software design since the 1990's and it's so much easier when the audience has enough experience that I can wave my hands and say "you know when things go like this ... ?" and they do, and then we can get on with how to think about it and do better.
Without that, it's tedious. Folks with less experience have the brainpower to understand but not the context. I try to create the context with a synthetic example, but (again, waving hands...) you know how much richness your current system has compared to any example I can put on a page or a slide.
> it seems like there’s no to little mention of performance metrics.
The book uses the jargon from the architecture community. Chapter 12 section 11 on Quality Attribute Scenarios is what you're looking for. But [1] seems to be a summary of Michael Keeling's treatment on qualities and scenarios, which I like better.
My thinking on this has been greatly influenced by Titus Winters who I've been teaching with in Google for the past couple years. He's tied together the ideas of quality attribute scenarios, compile-time tests, monitored metrics, and alerts in a way that is, in hindsight, completely obvious but I've not seen elsewhere. Maybe we can get him to write that up as an essay.
I read the article about quality attributes you linked. Interestingly it mixes attributes that are measurable, like performance and availability, but also ones that are very hard to measure like extensibility and adaptability.
The latter group of attributes are often not measured at all in my experience. I don’t even know of a way that lets me quantify those in a sound, practical way.
The opinions on how to optimize for these attributes are conflicting and full of contradictions. Nobody seems to have a clear model.
Simon Brown is another person who has done a far better job than me of "democratizing" software architecture for developers. His talks [1] and workshops on architecture are exceptionally effective and his C4 architecture modeling language [2] is getting real traction.
I have youtube videos too [3] but they aren't as effective.
Keeling's Design It book is great [1]. It helps teams engage with architecture ideas with concrete activities that end up illuminating what's important. My book tries to address those big ideas head-on, which turns out to be difficult, pedagogically, because it's such an abstract topic.
Which ideas have survived since 2010?
Some operating systems are microkernels, others are monolithic. Some databases are relational, others are document-centric. Some applications are client-server, others are peer-to-peer. These distinctions are probably eternal and if you come back in 100 years you may find systems with those designs even though Windows, Oracle, and Salesforce are long-gone examples. And we'll still be talking about qualities like modifiability and latency.
The field of software architecture is about identifying these eternal abstractions.
See [2] for a compact description.
"ABSTRACT: Software architecture is a set of abstractions that helps you reason about the software you plan to build, or have already built. Our field has had small abstractions for a long time now, but it has taken decades to accumulate larger abstractions, including quality attributes, information hiding, components and connectors, multiple views, and architectural styles. When we design systems, we weave these abstractions together, preserving a chain of intentionality, so that the systems we design do what we want. Twenty years ago, in this magazine, Martin Fowler published the influential essay “Who Needs an Architect?” It’s time for developers to take another look at software architecture and see it as a set of abstractions that helps them reason about software."
One of my main goals with the book was to "democratize" architecture, to make it accessible and relevant to every developer. As the cover blurb says:
"It democratizes architecture. You may have software architects at your organization — indeed, you may be one of them. Every architect I have met wishes that all developers understood architecture. They complain that developers do not understand why constraints exist and how seemingly small changes can affect a system’s properties. This book seeks to make architecture relevant to all software developers, not just architects."
In hindsight, my book hasn't been very good at that but perhaps it was a stepping stone on the path. Michael Keeling's book Design It: From Programmer to Software Architect does a better job of saying how developers can engage with architecture ideas. I'm a personal friend of his and a huge fan of his work. His experience report [2] on how to democratize architecture is what I aspire to do.
It's often taught as "nonfunctional requirements" or NFRs. The architecture community says "quality attributes". Why?
1) Not all qualities are requirements. Requirements tend to be pass/fail, either you meet them or you don't. Latency is a quality and typically lower is better, not pass/fail (though sometimes it is).
2) "Nonfunctional" in other contexts means broken. If you saw a machine with a sign on it saying "nonfunctional" what would you conclude?
At one point I tried to find the origin of the term "quality attributes". It's way older than the software community. I found it being used in the 1960's by the US National Academy of Sciences. If anyone knows the origin I'm interested in learning more.
For typical web / IT systems I largely agree with focusing on modifiability as a heuristic because on those kinds of systems it's typically the biggest risk.
But, have you seen this kind of mistake / failure? A system is built so flexibly that it can handle all kinds of future needs, but it's slow. Maybe it's a shopping cart that takes 5 seconds to update. So start with modifiability as the primary heuristic but keep an eye out for other failure risks.
Meta-commentary:
This is an example of why it's so hard to discuss architecture. My book talks about "failure risks", which is pretty abstract or generic. There's no easy heuristic for avoiding "failure risks" like there is for web / IT systems.
Software architecture is a discipline that's bigger than just web / IT systems. Some systems must respond with X milliseconds, otherwise the result is useless, so the architecture should make that possible -- and preferably make it easy.
"I’m not ready to argue against Brooks’ Law that adding people to a late project makes it later. But today, when developers are working on a clean codebase, I see lots of work happening in parallel with tool support to facilitate coordination. When things are going smoothly, it’s because the architecture is largely set, the design patterns provide guidance for most issues that arise, and the code itself (with README files alongside) allow developers to answer their own questions."
"There exists an identifiable programming style based on the widespread use of type information handled through mechanical typechecking techniques. This typeful programming style is in a sense independent of the language it is embedded in; it adapts equally well to functional, imperative, object-oriented, and algebraic programming, and it is not incompatible with relational and concurrent programming."
[1] Luca Cardelli, Typeful Programming, 1991. http://www.lucacardelli.name/Papers/TypefulProg.pdf
[2] https://news.ycombinator.com/item?id=18872535