JDD 2024: The four rules of simple design

## Overview

Thomas, a software developer with over 20 years of experience, presents the four rules of simple design—a set of principles first documented by Kent Beck in his Extreme Programming books (2000, 2004). These rules form a practical foundation for code quality that the speaker argues can replace or complement frameworks like SOLID, KISS, and others.

## The Four Rules

1. **Tests Pass** – Implies the existence of tests; without them, nothing can pass 2. **Reveal Intent** – Make code purpose clear through naming and structure 3. **Remove Duplication** – Eliminate redundant logic 4. **Small** – Keep classes and methods minimal

Thomas emphasizes these rules should be applied sequentially, repeatedly, and somewhat mechanically. The order of rules 2 and 3 can vary, as removing duplication often improves clarity and vice versa.

## Key Technical Demonstration

The speaker demonstrates applying these rules to the tennis kata (created by Emily Bache), a refactoring exercise involving a tennis score calculator with unusual scoring rules (love for 0, 15 for 1, 30 for 2, 40 for 3). Key refactoring steps include:

- Removing unused code identified by test coverage - Extracting methods to reveal tennis rules (winner, advantage, equal) - Inlining methods used in only one location - Converting string equality from `==` to `.equals()` - Creating a `getPointName()` method to eliminate repeated constants (15, 30, 40, love) - Simplifying conditional logic by identifying patterns and replacing multiple conditions with unified patterns - Using a lookup table (array) instead of switch/case statements - Converting fields to local variables where appropriate

## Critical Principles

- **Fast Test Suite:** Tests must run quickly (under 200ms ideally). Slow tests discourage refactoring and break flow - **Mechanical Application:** Apply rules consistently and without overthinking, running tests after each small change - **Small Steps:** The speaker emphasizes tiny, reversible changes to prevent breakage - **Definition of Done:** Software in production, used by real users—not just written or tested - **History Matters:** The software community often repeats past mistakes because it lacks historical awareness; these rules have been available for over 20 years

## Takeaways

Thomas demonstrates that by mechanically applying these four rules in small steps with a fast test suite, developers can significantly improve code clarity, reduce duplication, and maintain deliverability. The refactoring shown—starting from a complex, unclear method and ending with smaller, clearer components—proves the approach works without requiring a full rewrite. The speaker notes developers can ship safely at any point if tests pass, making this approach low-risk and pragmatic.