Cognitive Biases and Agile Architecture
summary
Wikipedia lists over 200 biases and software architecture repeatedly trips on confirmation bias, availability heuristic, base‑rate neglect and outcome bias when teams judge decisions by luck. Examples: choosing Reflux for React that later requires migration to Redux, and investing months in a bespoke VM deployment system that Docker makes obsolete. Practical counters are concrete: use agile threat modeling, write decision records that capture what was known, pair and rubber‑duck, and apply hypothesis‑driven debugging to separate skill from luck.
AI-written summary · about
chapters (16)
- 0:00Introduction and confidence
- 1:55What are cognitive biases
- 4:46Confirmation bias in architecture
- 6:51Uncertainty and zero risk bias
- 9:00Availability heuristic in risk
- 10:26Using models to counter biases
- 12:09Debugging and base rate fallacy
- 16:40Scientific method in debugging
- 18:46Architecture decision making
- 19:28Outcome bias in decisions
- 23:23Self-serving bias and luck
- 24:47Appropriate decisions over right ones
- 26:32Trade-offs in software architecture
- 28:02Confidence in uncertainty
- 31:50Changing confidence baselines
- 32:12Q&A on team biases
related talks
44mCognitive Biases Driven Architecture?
07mSAG Expert Interview #02: How Cognitive Biases Impact Software Architecture
44mBehavioral Software Engineering
55mArchitecture Blindspots, Biases, and Blunders: Avoiding Common Pitfalls in System Design
38mAgile Architecture
51mWhy We Need Architects (and Architecture) on Agile Projects
01h 00mAgile Architecture
39mOne Does Not Simply Make Architecture Decisions Alone: ADRs and Architec