Chaos Development: Removing software as the inhibitor of Agile
summary
Claims that adopting Smalltalk-style OO reduces change cost are backed by concrete results: a legacy Java model with 72 classes is refactored to 1,400 classes and average method size drops to 2.3 lines per method, enabling a three-release rewrite delivered on time and 20% margin; a separate fuzzy-problem system uses asynchronous microservices and an event bus to run 652 deploys that week, drive rapid experiments, and generate substantial revenue gains.
AI-written summary · about
chapters (27)
- 0:00Introduction to chaos
- 1:18Legacy systems and testing limits
- 3:45Chaos engineering in systems
- 6:10Chaos in development requirements
- 7:55Fuzzy vs traditional problems
- 12:30Two-part talk structure
- 13:12Chaos development definition
- 14:17Case study Nationwide Insurance
- 16:46Agile productivity gains
- 18:29Smalltalk programming techniques
- 20:55Simple design principles
- 23:24Encapsulation and code quality
- 25:11Avoiding control structures
- 28:20Focus on completion over work
- 30:30Overcoming team fears
- 32:34Handling changing requirements
- 34:19Fuzzy problems and experimentation
- 36:05Customer interaction for fuzzy problems
- 37:27Exploiting fuzzy problem traits
- 39:14Micro services for fuzzy problems
- 42:25Event-driven architecture
- 44:13Graceful degradation example
- 47:41Incremental system deployment
- 48:23Reverse Conway's law
- 49:05Reducing roles and processes
- 49:48Aggressive deployment stats
- 50:50Continuous deployment necessity
related talks
43mGo Ahead, Make a Mess
54mGetting Unstuck. Strategies for Surviving in a Rapidly Changing Post-Agile World
50mTactics and strategies on software development: how to reach ...
01h 21mTradeoffs in the Software Workflow
53mHatching software development ecosystems (the gordian knot)
01h 02mTools for simplified large scale systems
01h 00mBeyond the innovator’s dilemma
59mAgile Engineering: The Hard Parts