Software Architecture for Humans!
summary
Argues that architecture quality depends on human capacity not abstract ideals and gives concrete practices: use Structure101 for dependency and size metrics, conduct interviews plus behavioral code analysis to spot who changes what, write architecture decision records and Arc42-style docs, and prefer a requirements approach over rigid metrics when teams are trusted. Warns that metrics mislead (Goodhart example of rat bounties, code coverage gaming) and shows legacy as a social problem — people quitting can break maintainability. Also demos an email-to-OneDrive flow backed by Amazon Lambda.
AI-written summary · about
chapters (18)
- 0:00Software architecture intro
- 1:05Why architecture exists
- 3:11Architecture with team capacity
- 4:58Proving architecture
- 7:07Legacy systems as social issues
- 9:15Complexity vs maintainability
- 12:26Danger of valuing complexity
- 14:15Rewarding complex solutions
- 17:07Micro and macro architecture
- 18:10Enforcing static analysis?
- 22:44Requirements for autonomous teams
- 26:18Architecture by team trust
- 27:03Fixing orgs vs adapting architecture
- 28:28Q&A: Metrics for complexity
- 30:57Q&A: Code review complexity
- 32:20Q&A: Architecture docs
- 34:48Q&A: Building good teams
- 36:54Closing thoughts
related talks
48mArchitecture: The Stuff That's Hard to Change
45mArchitecture: The Stuff That's Hard to Change
46mTHE too MANY FACES OF ARCHITECTURE
49mWhy software architects fail: and what to do about it
01h 09mAgile Software Architecture
37mArchitecting for Tomorrow: A Pragmatic Perspective
45mFive things every developer should know about software architecture
45mTeam and Software: Making an Impact as an Architect