Shiny objects are cool, but so is building products people use
summary
Argues that chasing new frameworks and clever code wastes effort on accidental vs essential complexity (cites Fred Brooks), gives concrete failures — an e‑reader built in four JS frameworks, dozens of unfinished Eclipse projects, dependency pain from an outdated reCAPTCHA gem that a one‑line custom fix replaces — and prescribes practices: time‑box experiments, use simpler infrastructure like Heroku for early MVPs when staffing is small, apply the five whys, and prefer maintained libraries with active users.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:39What is shiny
- 4:40Brooks Law
- 5:51Accidental Complexity
- 6:49Essential Complexity
- 9:27Problem with Shiny
- 12:10Why Shiny
- 15:16Focus on the problem
- 18:20Focus on the customer
- 24:54Examples
- 26:03Should I use this library
- 38:37How do we innovate
- 46:49Evaluating and choosing
