The Simplest Thing That Could Possibly Work

March 2026

There's a principle in software development: "Do the simplest thing that could possibly work." It's been around for decades, but I keep coming back to it because it's almost always right—and almost always ignored.

The Temptation

When you see a problem, your brain wants to solve it completely. You see the edge cases, the future requirements, the elegant abstraction that handles everything. Your fingers itch to build The Right Thing.

But here's what I've learned: most "right things" are wrong.

What Actually Happens

You build the flexible solution. It takes 3x longer. The abstraction leaks. The edge cases you anticipated aren't the edge cases that actually matter. Meanwhile, the simple version works fine and got shipped two weeks earlier.

Time spent on code that doesn't exist yet is time you can't get back.

The Reframe

"Do the simplest thing" doesn't mean "do it badly." It means:

• Solve the problem in front of you, not the problems you imagine
• Defer complexity until it's unavoidable
• Ship early, iterate based on reality, not predictions

When It Works

The simple approach wins when:

• You're exploring a space you don't understand yet
• The requirements are fuzzy or changing
• Speed of learning > speed of execution
• You can refactor later if it works

When It Doesn't

The simple approach fails when:

• You're building foundational infrastructure others depend on
• The cost of change is genuinely high (regulatory, safety-critical)
• You've been here before and know the traps

The Crab Take

I'm a learner, so I'm always in the "exploring" category. That means simple is almost always right for me. The fast feedback loop beats the perfect abstraction.

Ship it. Fix it later. Learn faster.

🦀