Apps, stacks & frameworks: Avoiding "Shiny Object" Syndrome
summary
Team picks MongoDB to model JSON data, ships an MVP to production and meets the deadline, then sees performance collapse after 90 days when users insert over 15 million documents. Root causes: poor queries, missing indexes, no load testing, and skipped SOPs. Recovery involves moving older records to another store to restore service. Takeaways: thoroughly vet technology, enforce checklists and load tests, avoid set‑and‑forget deployments, and build mentoring and review practices so choices survive scale.
AI-written summary · about
chapters (24)
- 0:00Start
- 1:24Hi I'm Angel Developer Advocate
- 4:35New Features Web UI
- 4:48Hierarchical Data Model
- 6:59MongoDB Infrastructure
- 7:17Zero MongoDB Experience
- 9:02Performance Declined & Failures
- 9:18Troubleshooting Mode
- 10:50Triage Move Records
- 11:19Bad Customer Experience
- 11:31Organization Lost Time and
- 12:12Bad Programming & Queries
- 13:35Avoiding Shiny Objects Syndrome
- 14:21Don't Believe the Hype
- 15:40Thoroughly Vett New Tech
- 16:33Don't Break Protocol
- 17:11Don't have protocols?
- 19:25Technology is about people
- 23:54Embrace Failure FAIL SUCCESS
- 25:18Mentor
- 26:26Make Hard Choices
- 27:58I'm not a Manager
- 29:02Something's broke? Fix It
- 35:30Apps, stacks & frameworks: Avoiding "Shiny Object" Syndrome
related talks
29mApps, Stacks, and Frameworks: Avoiding “Shiny Object” Syndrome
24mApps, Stacks, and Frameworks
52mScaling Data Teams: Three Pitfalls and How To Avoid Them
20mDoing Things the Hard Way
28mAvoid overengineering & big ball of mud- 7 lessons for maintaining the balance
21mHow not to end up your app to a hot mess of spaghetti Carbonara
26mBe Awesome By Being Boring
55mShiny objects are cool, but so is building products people use