GeeCON 2019: Fred George - Chaos Development: Removing software as the inhibitor of Agile

### Overview In this talk, Fred George discusses "Chaos Development"—an approach to designing software processes and architectures that accept and accommodate constant requirement changes rather than trying to control or suppress them. Drawing parallels to chaos engineering, where production systems are built to withstand and recover from unpredictable infrastructure failures and attacks, chaos development focuses on eliminating software development practices that inhibit agility. George explains that development environments have shifted drastically from the 1970s mainframe era of small codebases and isolated machines to massive enterprise codebases with shifting requirements and distributed integrations. Using the Cynefin framework, he differentiates between traditional (simple/complicated) problems and fuzzy (complex/chaotic) problems, presenting distinct development and architectural paradigms for each.

### Key Topics - **Evolution of Systems and Fallibility of Testing**: From small IBM 1130 programs of 4,000 lines to 100-million-line codebases, modern systems inevitably suffer from bugs—both internal and external (such as failing third-party APIs). Acceptance testing is increasingly superseded by active production monitoring and resilience engineering. - **Traditional vs. Fuzzy Problems (Cynefin Framework)**: Traditional/complicated problems have cause-and-effect relationships where domain experts and story-driven Agile workflows excel. Fuzzy/complex problems (such as recommendation engines, Google advertising, and financial markets) lack predictable cause-and-effect; in this domain, no true experts exist, making rapid experimentation essential. - **Extreme OO and Agile for Traditional Systems**: For traditional systems, agile productivity comes from manufacturing-style flow, minimizing work-in-progress, and writing code engineered for rapid change using Smalltalk-inspired object-oriented design. - **Asynchronous Microservices for Fuzzy Systems**: For fuzzy domains, tiny, decoupled microservices connected via an asynchronous event bus enable continuous deployment, rapid experimentation, and graceful degradation.

### Technical Details - **Smalltalk-Style Object-Oriented Design Rules**: - Keep methods extremely short (averaging ~2.3 lines per method at Nationwide, and ~1.5–1.6 in Kotlin). - Minimize class sizes (averaging around 25 lines of code) and avoid "God classes" or classes ending in `-er` / `-or` (e.g., Managers, Calculators). - Strictly enforce encapsulation: eliminate public variables, getters, and setters. - Eliminate conditional complexity: avoid `switch`/`case` statements, `else` branches, enums, and non-guard `if` statements, replacing them with patterns such as State or Strategy. - Avoid primitives representing behavior: eliminate raw booleans, unstructured maps, naked numbers, and raw strings from core domain models. - **Microservices & Event Bus Architecture for Fuzzy Systems**: - Built as very small units (often 30–40 lines of code) developed by single individuals ("team size of one"). - Implement the **Need Pattern** over an event bus: a service publishes a need (e.g., deciding whether to issue a loan or serve a promotional ad), and independent, decoupled services publish offers or evaluations asynchronously. - Tolerate eventual and delayed consistency (even days out of date) and lack of strict transactions. - Rely on graceful degradation: if an individual service or external feed fails, the broader choreography still yields answers. - Support ultra-high deployment velocity: George describes a London startup running ~300 microservices where 53 developers made 652 production deployments in a week (a release every 3.5 minutes on average).

### Takeaways - Organizations must match their engineering processes to the nature of the problem: traditional/complicated problems benefit from disciplined Agile, Smalltalk-style design, and domain stories, whereas fuzzy problems require discarding traditional ceremonies in favor of autonomous developers experimenting directly. - In fuzzy domains, competitive advantage belongs to whoever can try out ideas fastest; experimentation drives innovation. - Investing directly in developer skills through continuous pair programming and eliminating organizational fears (e.g., fear of failure, fear of inaccurate estimates) yields far greater productivity gains than management tooling alone.