High Optionality Programming: Architectural Choices That Mitigate Technical Debt
summary
Argues that paying a small upfront premium buys options that prevent huge future rewrites, and proves it with a startup case: an analytics product spikes from ~10k to 5–8M events/day, RavenDB can’t keep up, and an emergency refactor moves to an event-driven pipeline with read/write separation, middleware to emit analytic deltas, unit tests restored, and a RavenDB → Cassandra migration that supports ~100 million events/day. Recommends event-driven design, event sourcing, CQRS, actors, and extend-only schema/versioning as concrete techniques.
AI-written summary · about
chapters (17)
- 0:00High Optionality Programming intro
- 2:31Technical debt costs
- 7:24Optionality concept
- 9:50Database pitfalls
- 11:57RavenDB to Cassandra migration
- 17:08YAGNI risks
- 19:57Preserving optionality techniques
- 26:20Event-driven benefits
- 31:39Event sourcing flexibility
- 36:33Command Query Responsibility Segregation Explained
- 41:23Actors in dynamic systems
- 42:48Extend-only design
- 51:37Upfront costs vs benefits
- 54:29Selling to startups
- 57:21Design rules in CI/CD
- 59:06Event partitioning
- 1:00:10Q&A
