Why software architects fail: and what to do about it
summary
Argues that architecture fails when people overgeneralize, build early generic platforms that create vendor lock-in, chase novelty for status, or let analysis paralysis stall vendor choice; recommends concrete countermeasures: limit changes with an innovation token (e.g. two allowed new technologies), run fast proofs of concept, enforce a few minimal rules, prefer pragmatic minimal designs, keep architects involved in delivery and coding where possible, and treat architecture as salesmanship: communicate, defend, and iterate on real results.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 4:20Why architects fail
- 8:35Overgeneralization drive
- 10:44Main allergy and generic machines
- 14:20Danger of specific solutions
- 17:13Unnecessary complexity
- 19:19Analysis paralysis
- 21:46Innovation addiction
- 26:05Fixation on paradigms
- 29:36Hammer and nail problem
- 31:00Risk aversion and outdated practices
- 32:44Easy versus simple
- 35:13Impact dissonance
- 38:46What architects should do
- 41:35Success formula
- 45:45Q&A
related talks
46mTHE too MANY FACES OF ARCHITECTURE
48mArchitecture: The Stuff That's Hard to Change
45mFive things every developer should know about software architecture
51mSoftware Architecture for Humans!
45mSoftware Architecture for Humans!
37mSoftware Architecture for Humans!
45mFive things every developer should know about software architecture
45mTeam and Software: Making an Impact as an Architect