The simplest thing that could possibly work
Start simple, learn, iterate, advance
Why is it that when we're building something new, we sometimes get out over our skis with a complex plan before we've done anything? I've got no problem with planning, but there's virtue in starting. Starting simple and allowing our learnings to inform us along the way.
When working through problems, the most impressive creators aren’t those that divine an entire solution from scratch in their brain for an hour, then bang out a perfect result (spoiler: this doesn’t exist anyway). What I love to see is someone that deftly, persistently breaks down a complex problem into simpler ones. A developer that reduces the problem and ranks the bottleneck steps to work through first, second, third, etc.
Some people are good at avoiding the temptation to overcomplicate. They break problems down, simplifying complex problems by isolating parts. Then they block-and-tackle their way forward from there.
There’s a great excerpt on this idea from an interview with Ward Cunningham, programmer and inventor of the wiki (emphasis mine):
But other times we'd be programming away, and we'd say, "Now, wait a second, what are we working on here?" We'd just get stuck. And if we were stuck more than a minute, I'd stop and say, "Kent, what's the simplest thing that could possibly work?"
It was a question: “Given what we’re trying to do now, what is the simplest thing that could possibly work?” In other words, let’s focus on the goal. The goal right now is to make this routine do this thing. Let’s not worry about what somebody reading the code tomorrow is going to think. Let’s not worry about whether it’s efficient. Let’s not even worry about whether it will work. Let’s just write the simplest thing that could possibly work.
Once we had written it, we could look at it. And we’d say, “Oh yeah, now we know what’s going on,” because the mere act of writing it organized our thoughts. Maybe it worked. Maybe it didn’t. Maybe we had to code some more. But we had been blocked from making progress, and now we weren’t. We had been thinking about too much at once, trying to achieve too complicated a goal, trying to code it too well. Maybe we had been trying to impress our friends with our knowledge of computer science, whatever. But we decided to try whatever is most simple: to write an
ifstatement, return a constant, use a linear search. We would just write it and see it work. We knew that once it worked, we’d be in a better position to think of what we really wanted.
I previously wrote that triage is a skill, which you can train through practice like any other. I defined it generally as:
The assigning of priority order to projects on the basis of where funds and other resources can be best used, are most needed, or are most likely to achieve success
Triage is, fundamentally, scarce resource management. When we're looking for the simplest thing, what we're really trying to avoid are all the less-simple (but maybe more attractive) possibilities that will sap resources for no ends. The fancy, complex approach that might work, but it also might cost an entire day's worth of time and effort. Doing the simple thing first let's us work through each possibility with a valid, functional thing before we move to the next one. The simple must work before the complex can work. It's a Gall's Law-compliant strategy.
When Cunningham says "the mere act of writing it organized our thoughts," he's speaking to this idea that it's rarely possible to know the specifics of the goal (or the means to get there) until you get started. Starting on the thing kickstarts the discovery engine.
Nearly every time I'm doing anything creative — building a software feature, writing an article, building something in my shop — the final state ends up somewhere other than what I predicted at the start. During the process of making, I learned things, or I came to realize things I didn't know I needed or wanted.
When you’re just getting started, you don't know what the possibilities are yet. To know what to build, you've got to start building.
The most prolific engineers I’ve worked with have a knack for this type of chewing through the work. The simplest thing usually isn’t the cleanest, fewest lines of code, fewest moving parts, or the most well-tested. Simple means “does a basic function”, something you can categorically check and verify, something a collaborator can easily understand.
Sometimes you just need to first do the Simplest Thing before you can find the Correct thing.