software architecture is like regular architecture but civil engineering does not exist because there hasn't been an Isaac Newton of software. I'd say the closest so far is Claude Shannon
This has profound effects for self reported productively.
For example, biking feels faster than driving 30mph with the windows up down a small suburban road with lots of stop signs. But typically the driver will still get 20 blocks away much much faster.
However if we had no units of measurement, everyone would be arguing the bike was faster.
This is where we are with software engineering.
The only companies that really have enough data are the consulting giants. And they have enough perverse incentives that I would be extremely sceptical of their data.
With big architecture projects you first design them and then build them. This is a lot of work. You have to think about everything, run simulations, engage with stakeholders, figure out requirements and other constraints, think about material cost, weight, etc. Months/years can be lost with big construction projects just coming up with the designs. The result is a super detailed blueprint that covers pretty much all aspects of building the thing.
It's a lot like building software, actually. These design projects have a high degree of uncertainty, risk, etc. But it's better than finding out that it's all wrong before you start building and using massive amounts of people, concrete, steel, and other expensive resources. But when have you ever heard an architect talk about making a design for their design to mitigate this? It's not a thing. There might have been a sketch or a napkin drawing at some point at best. SpaceX has introduced some agile elements into their engineering, which is something they learned from software development.
With software, your finished blueprint is executable. The process of coming up with one is manual, the process of building software from the blueprint is typically automated (using compilers and other tools) and so cheap software developers do it all the time (which wasn't always the case). The process of creating that executable blueprint has a lot of risks of course. And there might be some napkin/whiteboard designs here and there. But the notion that you first do a full design and then a full implementation (aka. waterfall) was never a thing that worked in software either. With few exceptions, there generally are no blueprints for your blueprint.
Read the original paper on Waterfall by Royce. It doesn't actually mention waterfalls at all and it vaguely suggests iterating might be a good idea (or at least doing things more than once). He fully got that the first design was probably going to be wrong. Agile just optimized away the low value step of creating designs for your blueprints that becomes apparent when you iterate a lot.
For example, from glancing at this summary and table of contents, it seems like there’s no to little mention of performance metrics. What is architecture good for if it doesn’t account for what the computer actually does?
Even in terms of development productivity or UI: why don’t we have mathematical models to decribe the mental stack one needs to develop, change, extend and more importantly use software?
Why are compute resources (human or machine) rarely a consideration when they have a real, measurable impact on interacting with software as developers or users?
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.
[1] https://dev.to/frosnerd/quality-attributes-in-software-1ha9
[2] Titus Winters, Design is Testability, May 8 2024. https://on.acm.org/t/design-is-testability/3038 (note: video doesn't seem to be posted yet)
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.
What is your take on this?
Same applies to much of software.