THE too MANY FACES OF ARCHITECTURE
summary
Argues that software architecture is not an elite art but a practical, team-shared responsibility and that architecture is a role not a title, requiring both technical fluency and leadership. Recommends delaying irreversible choices, designing evolvable architectures that tolerate changing requirements, and keeping architects close to code via pair programming, code reviews, ownership of features and even targeted unit tests for architecture. Emphasizes measuring significance by cost of change, using team expertise to surface risks early, and coaching developers to grow into architecture responsibilities.
AI-written summary · about
chapters (6)
- 0:00Start
- 8:24Define what is significant Define why is significant
- 16:37God of the whole tech stack • Defines & guards architecture
- 21:49Often leadership weights more than management
- 29:26Architecture is for every developer but is every developer prepared to become an architect?
- 31:16Coders gonna code and architects gonna architect?
related talks
25mThe (too) Many Faces of Architecture
01h 09mAgile Software Architecture
51mSoftware Architecture for Humans!
49mWhy software architects fail: and what to do about it
45mFive things every developer should know about software architecture
48mArchitecture: The Stuff That's Hard to Change
49mAs Much Architecture Work as Necessary
45mTeam and Software: Making an Impact as an Architect