The Simplest Design

The definition of the best design is the simplest design that runs all the test cases.

-Kent Beck

A photograph by yours truly.

While reading “Extreme Programming,” I’m reminded by the concept of the simplest design for a codebase. Thinking about code in this sense — minimalism — is a useful endeavor. I’m a pretty minimalist person (not in the sense that I own exactly 150 items or anything like that). After moving across the country twice, you can bet that I’ve discarded just about everything that does not bring me joy. If you step into my apartment, you’ll notice that nothing is seemingly out of place. Each object belongs in its respective home. During the times when things go haywire, I resume order at the end of the day. In other words, simplicity and purposefulness make sense to me.

I’m typically interested in conceptual paradigms — in this case, Beck design the design as a “communication medium” wherein the objects and methods represent important concepts. The purpose of the design is to communicate our intent as programmers and to store the logic of the system, which will have many components that will work together. Beck outlines the following constraints in priority order.

1. The system, which includes the code and tests, must communicate everything that you want to communicate. (A bit vague).
2. The system does not contain duplication. 😳
3. The system should have the fewest possible classes.
4. The system should have the fewest possible methods.

This reminds me of previous readings that I have encouraged us to use dependency injection to only communicate what needs to be known. Or to encourage reusability of methods within the code. Removing duplication is not easy — most of the time, I only streamline certain parts of the code when I find myself writing the same thing over and over again. It’s part of the process. You identify the duplication, you eliminate it, and you write code that can be repurposed.

“You delete everything that doesn’t have a purpose — either a communication purpose or a computational purpose.”

Also, Beck encourages us to just delete it. This is similar to the notion that we should unabashedly write and eliminate code if it’s not working or non-ideal. But he also bids us to delete things that are utterly useless and think of this process as erasure. For my hosted tic-tac-toe project, I found myself with two extraneous endpoints and logic that either 1) ultimately served no purpose, or 2) could be coupled with logic elsewhere. Perhaps the process of thinking about them and writing out their perceived roles and responsibilities was a helpful exercise in realizing that less is more.

Codebases get complex — and quickly, too. But may we always remember to be as focused on the beauty of simplicity as much as possible.