Tog's Paradox: Why Requirements Always Spiral Out of Control
summary
Argues that complexity just moves between user and system using Tesler's Law and Tog's Paradox, shows that removing friction raises user expectations, and gives concrete countermeasures: use MoSCoW/CANO prioritization, publish a roadmap, timebox decisions, add telemetry (example: telemetry revealed ~25% widescreen users so the UI was adjusted), expose domain knowledge to developers via a person, and build small modules and a CLI for power users — implemented and used successfully.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:02Changing requirements after delivery
- 6:10Larry Tesler's Law
- 9:59Tog's Paradox explained
- 14:39Tesler's Law and Tog's Paradox
- 17:30Spiraling requirements symptoms
- 21:21Avoiding over-engineering
- 23:28Roadmaps and user trust
- 25:58Time-boxing decisions
- 27:46Telemetry and user analytics
- 28:51Rebuilding trust
- 30:17Simplicity versus power users
- 32:42Complexity transfer to developers
- 34:25Key takeaways
related talks
43mUser Experience and complexity
29mEmbracing Complexity: Lessons From Product Teams
36mThe human factor you might be missing when designing your system
25mOverengineering 101: what is it and how to avoid it?
01h 00mTackling Socio-technical Complexity in the Heart of Your Team
41mA Defence of Technical Excellence
47mDecoding paradoxes: why are many good ideas in software delivery counter intuitive
38mMore Money More Problems