Software Architecture for Humans!
summary
Argues that architecture must match the people working on it, not just the dependency graph, and shows concrete fixes: run behavioral code analysis (who edits what) alongside metrics, invest one to two years to onboard someone into a legacy system rather than a full rewrite, and prefer team autonomy over rigid static code analysis thresholds because Goodhart’s law breaks metric targets. Uses a Java compiler experiment to prove exotic language features harm maintainability and cites Accelerate and the inverse Conway maneuver as practical governance options.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:45Defining Great Architecture
- 3:19Reviewing Architectures
- 4:33Social Aspects of Code
- 6:08Improving Architecture
- 8:08The Human Factor
- 9:40Team Education
- 11:21Legacy Systems
- 14:04Big Ball of Mud
- 17:35Developer Behavior
- 21:08Java Certification Example
- 25:01Micro Architecture
- 29:00Measure as a Target
- 30:53Team Autonomy
- 32:19Inverse Conway Maneuver
- 35:31Conclusion
- 38:34Q&A Session
related talks
51mSoftware Architecture for Humans!
24mThe too many faces of Architecture
49mWhy software architects fail: and what to do about it
41mSoftware Architecture in a DevOps World
38mAgile Architecture
07msoftware architecture vs code
48mArchitecture: The Stuff That's Hard to Change
46mTHE too MANY FACES OF ARCHITECTURE