DumbDev -- eight rules for dumb development
summary
A concrete method: limit each subsystem to one central concept with up to eight neighbors, and never more than two levels deep — filling two levels yields roughly 500 concepts as a practical complexity ceiling. Prescribes rules (decouple, midi services instead of tiny microservices, borrow from OSS, per-module verification, explicit errors), live paper-and-pair exercises, and a proposal for small tooling that visualizes maps and enforces per-module tests. Demonstrations run interactively, applied recursively to the methodology itself, with website dumbdev.io for followup.
AI-written summary · about
chapters (10)
- 0:00Introduction to dumb dev
- 1:15Memory exercise and recap
- 3:43The hash limitation principle
- 7:27Group discussion exercise
- 10:21Managing complexity with depth
- 17:04The DUMB acronym explained
- 21:28Knowledge fragility and satnav
- 25:48Applying constraints to projects
- 30:01Verification and error handling
- 33:54Q&A and conclusion
related talks
57mCore Software Design Principles for Programmers
53mIntentional Code - Minimalism in a World of Dogmatic Design
15mThe Moderate Programmer
31mThe Effective Developer - Work Smarter, Not Harder
47mHow To Build Future Proofed Applications
39mClean, Concise, Collaborative Code
50mIntentional Code - Minimalism in a World of Dogmatic Design
35mMind Over Error