The ultimate goal of good architecture is cost reduction. If your architecture is causing you to spend more time developing and maintaining code then the architecture has failed.
I like “Design It” because of some of the workshop/activities that are nice for technical folks who need to interact with stakeholders/clients (I’m in a consulting role so this is more relevant). Also it doesn’t lean hard on specific technical architectural styles which change so frequently…
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
It's still on my reading list, though. I've moved on from that company. But it came highly recommended, because they also documented their architecture with the C4 model.
Has anyone here read it?
How much are they paying the CEO?
Don’t they consider their replacement costs in the hundreds of millions.
MBA management types strive to convince everyone they are irreplaceable.
Engineers proudly talk about how they are easily replaceable.
Guess who gets shit on?
It is actually good that losing engineering talent be extremely painful for a company. This helps prevent the slow loss of engineering culture like what happened at Boeing.
Give me the mathematical model and that's it. No more vague, human-created terms to try to translate your own ideas, that's just a hack.
> software engineering risks: “The server may not scale to 1000 users”
> You should distinguish them because engineering techniques rarely solve management risks, and vice versa.
It's not so rare in my experience. Code quality and organization, tests and documentation, using standard and well known tools - all of those would help both sides here.
That's why I've had to invoke the "hit by bus" hypothetical so many times in my career with colleagues and bosses, because it's a forcing function for reproducible and understandable software.
Pro tip: use "win the lottery" instead to avoid the negative connotation of injury or death.