reducing-entropy
Use when evaluating designs, reviewing code, or refactoring - measures success by total code in the final codebase, not effort to get there. Bias toward deletion.
When & Why to Use This Skill
The Reducing Entropy skill is a specialized tool for codebase optimization and technical debt management. It empowers developers to maintain a minimalist and efficient codebase by prioritizing code deletion over accumulation. By focusing on the final state of the repository rather than the effort of implementation, it provides a rigorous framework for evaluating designs, refactoring legacy systems, and conducting high-impact code reviews that combat software bloat.
Use Cases
- Refactoring legacy modules: Systematically identifying and removing redundant functions or obsolete logic to simplify the codebase.
- Design Evaluation: Assessing new feature proposals to ensure they represent the smallest possible architectural footprint required to solve the problem.
- Aggressive Code Reviews: Using a 'bias toward deletion' mindset to reject over-engineered abstractions and 'just-in-case' code that increases maintenance overhead.
- Technical Debt Reduction: Measuring the success of a sprint or task by the net reduction in total lines of code, ensuring the system remains lean and manageable.
| name | reducing-entropy |
|---|---|
| description | Use when evaluating designs, reviewing code, or refactoring - measures success by total code in the final codebase, not effort to get there. Bias toward deletion. |
Reducing Entropy
More code begets more code. Entropy accumulates. This skill biases toward the smallest possible codebase.
Core question: "What does the codebase look like after?"
Before You Begin
Load at least one mindset from references/
- List the files in the reference directory
- Read frontmatter descriptions to pick which applies
- Load at least one
- State which you loaded and its core principle
Do not proceed until you've done this.
The Goal
The goal is less total code in the final codebase - not less code to write right now.
- Writing 50 lines that delete 200 lines = net win
- Keeping 14 functions to avoid writing 2 = net loss
- "No churn" is not a goal. Less code is the goal.
Measure the end state, not the effort.
Three Questions
1. What's the smallest codebase that solves this?
Not "what's the smallest change" - what's the smallest result.
- Could this be 2 functions instead of 14?
- Could this be 0 functions (delete the feature)?
- What would we delete if we did this?
2. Does the proposed change result in less total code?
Count lines before and after. If after > before, reject it.
- "Better organized" but more code = more entropy
- "More flexible" but more code = more entropy
- "Cleaner separation" but more code = more entropy
3. What can we delete?
Every change is an opportunity to delete. Ask:
- What does this make obsolete?
- What was only needed because of what we're replacing?
- What's the maximum we could remove?
Red Flags
- "Keep what exists" - Status quo bias. The question is total code, not churn.
- "This adds flexibility" - Flexibility for what? YAGNI.
- "Better separation of concerns" - More files/functions = more code. Separation isn't free.
- "Type safety" - Worth how many lines? Sometimes runtime checks in less code wins.
- "Easier to understand" - 14 things are not easier than 2 things.
When This Doesn't Apply
- The codebase is already minimal for what it does
- You're in a framework with strong conventions (don't fight it)
- Regulatory/compliance requirements mandate certain structures
Reference Mindsets
See references/ for philosophical grounding.
To add new mindsets, see adding-reference-mindsets.md.
Bias toward deletion. Measure the end state.