Worse Is Better, for Better or for Worse
summary
Argues that the successful pattern is deliberate minimal invention: prioritize simple, small, fast implementations that interoperate with existing tools over feature bloat. Cites concrete cases — the first editable web implemented in 200 lines of Perl (1995) and Unix’s tiny, enduring core — and contrasts that with richer but less adopted systems like Smalltalk. Emphasizes measurable usability: target 100 ms responsiveness, make features correct and consistent, and prefer throwaway small releases so the product can be changed quickly.
AI-written summary · about
chapters (21)
- 0:00Start
- 2:07Things every Programmer Should Know
- 3:42There Are a Thousand Thoughts Lying within a Man that He Does Not Know till He Takes Up the Pen To Write
- 6:31Knowledge-Based Discipline
- 7:31What Do We Want in the Artifact
- 8:56Danger of a Distraction
- 11:35Why Does the Market Not like It
- 11:48The Invisible Hand of Economics
- 12:49The Unreasonable Effectiveness of Mathematics
- 16:27Good Enough Software
- 18:19The Worse Is Better Approach
- 22:07Patterns of Software by Dick Gabriel
- 26:24Consistency
- 28:38Critical Decisions
- 33:36Unit Bias
- 36:36You Have the Microsoft Approach Which Was Characterized Very Much by the Good Enough Software Approach and Microsoft Will Load Loads of Extra Features in if You'Re a Developer and You Had an Idea for a Feature Then Pretty Much It Was Yes Put It in whereas What We What We'Re Seeing Here Is a Restraint on Actually no no no Don't Put that Feature in Just Just Hold Back a Minute because There Will Be another Release That's a Very Important Idea that this Is Not Your One Shot the Market Is Not Going To Judge You Forever More on a Perfectly Conceived Product unless Its Name Is Bob
- 36:57That's a Very Important Idea that this Is Not Your One Shot the Market Is Not Going To Judge You Forever More on a Perfectly Conceived Product unless Its Name Is Bob Not Enough Memories There Yeah Where's Where's Where's the Organizational Memory Microsoft Bob Go Look It Up on Wikipedia Have a Chuckle Have a Laugh It's Great Fun You'Ll Know So Let's Turn this One on Its Head We Normally Think of the Interface if We'Re Thinking of the User Experience We'Re Normally Thinking of the Interface
- 45:49And We'Re Going To Do this but There's Something Else As Well and this this Slide Is Guilty of It because It Puts Everything in a Straight Line and There's a Term That I'Ve Come To Think of in the Last It's Only Occurred to Me this Year Speaking to Clients either on Training Courses Are in Consultancy People Say Oh Yeah We'Ve Got a Product Roadmap People Use this Term Roadmap It Doesn't Mean What I What They Think It Means a Road Map Is It's a Map of Roads
- 48:01You Know What the User Is Going To Look for When They Actually Use Something That You Know What the Customer Is Going To Use this for that You Know the Best Way To Implement It at the Beginning at the Point of Greatest Ignorance Is a Major Assumption Now We Can See that There's a Lot of Crossover Here with What We Hear and See in a Lot of Agile Discussion and that the Ux Community Has Been Waking Up to Agile in Recent Years because a Lot of ux People Were Very Much of the Opinion that Well You Know You Can't Do It Eration Zoar You Can't Do this Incremental
- 48:43The Word Soft Is Really Important Here It's Also an Experiment You'Re Constantly Running an Experiment Hypothesis Validation this Is Often Overlooked at the Beginning of an Iteration if You Use an Iterative Life Cycle You Are Effectively Posing a Hypothesis You'Re Not Simply Saying We'Re Going To Deliver these Stories We'Re Actually You'Re Saying Something Deeper We Believe We Can Develop Given Our Current Skills Our Current Architecture and Our Current Understanding of What Is Needed We Can Develop this Amount of Product in the Next Couple of Weeks at the End of that You'Ve Run the Experiment You Have some Kind of Confirmation
- 49:26So in Closing We Recognize that Property Gain Control of the Design Process Tends To Feel like One Is Losing Control of the Design Process It's Almost an Opposite Feeling It's Not a Control Anymore that You Are Actually Embracing this Idea of Uncertainty but Also Doing this Tentative Exploration this Hypothesis Forming an Evaluation and at all Levels Sometimes People Think that Just Applies to the People Cutting Code It's no It's Actually at the Product Level this Is One of the Dangers Sometimes of Having the Concept of a Product Owner outside of the Core Development Team Having a Separate Special Specialist Ux Team Separated
