Software Design: Myths and Legends
summary
Ten common myths about software design are debunked with concrete Java and GraphQL code examples and measurable anecdotes, arguing that investing in internal quality speeds feature delivery and that poor design can turn small changes into days of work. Demonstrations cover a leaking public static global serializer, module sizing guided by the rule of three and Miller’s 7±2, when to generalize versus keep intentional duplication (DRY trade-offs), and practical fixes you can apply immediately.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 3:01Quality slows development
- 7:58Technical debt sources
- 13:48Bad module boundaries
- 22:277±2 rule in modules
- 26:26Overengineering vs YAGNI
- 35:40Self-documenting code
- 40:44DRY always improves code
- 46:43Flow in programming
- 51:24Summary myths and takeaways
- 52:07Q&A
related talks
45mMyth-Driven Design
57mCore Software Design Principles for Programmers
08mLightning talks – 101 Things Software Never Learnt
35mReviving the art of software design
20mSoftware design
34mHow do our ideas about coding affect the software we create?
53mSoftware Design: Beyond Boxes & Lines
41mThe lost art of software design