Simple (almost) always wins

Stories, Applications, and history repeating itself

(No AI writing in this one, promise!)

It’s a bitter pill for most engineers (and most people who make a living thinking or writing) but the reality is that “simple, but a little bit less right or complete” virtually always beats “right and complete, but more complex”. This is the lesson of “the rise of worse is better” that I’ve talked about many times. It shows up in all kinds of places, though, not just technology.

This week one company (Google) did a huge developer event with a bunch of complicated (and impressive) new ideas. Some were shipping, some were preannouncements, there was a lot to digest (20 links on the main page). It was not simple, but it was … thorough, let’s say. And then the next day, Open AI announced one thing (Jony Ive joining) and that sucked all of the air out of the room - even though no one knows what that product will be, or when. Simple story with a lot of missing pieces beats a complicated one.

This will probably happen with other parts of software too. I’m watching now as people around me build micro applications constantly. These give “real” engineers shivers - they’re not even tested! They’re missing a bunch of edge cases! Yes, but…they’re simple. Easy to tell the model to make you some small thing to do the task at hand.

Technology shifts often expose a new way of doing things that is simpler than before. This is usually where the opportunity comes from. I’ve told the story of Google Docs, that the technical change in distribution mechanisms (the internet) let us change what was being offered and find a new level of simplicity. It turns out, no one needed most of what Word was offering (footnotes! bibliographies!) most of the time. All of that was useful to someone at some point, but most of it was just in the way. Simple beat complete (at least to a degree).

I suspect we are going to see a lot of this start to emerge now that engineers aren’t really the bottleneck anymore. Lots of places where the simple thing, asking an LLM for a small solution, will beat the bigger and more complex thing. In fact, what I predict is that the larger applications will become more like support services - they will have more complex, rich functionality for when you need it, but that will be rare (at least for most people).

One last example is search. Google for a long time was successful in search because it was simple, in the sense of “I just go here and ask and they help me”, even if the product itself got more complex (image search, local search, shopping, etc). But now there’s a new kid in town - LLMs. And they’re even more simple (and even less correct often) - ask and I’ll just give you the answer or do it for you. Or even help you think about the problem. It’s a challenge for Google - search doesn’t feel like the simplest solution now, because the problem space has expanded and a new tech has arrived that is allowing “simple” to be redefined.

If you build software now for a living, you have assumptions about where your value lies that are probably wrong. You have spent a lot of time and energy mastering the complexities of real, robust, scaled software. Those problems still exist and need to be solved, but there will be immense pressure on not presenting any of their effects to end users now - users will demand (and get) simple, because it’s in reach. It’s critical now to understand this shift - what made sense before won’t make sense now, and, like it or not, users will go where the simplest thing is. It’s very easy as an engineer to waste time and energy making something complete, correct…and irrelevant.

Simple (usually) wins!