Simplify, Then Add Lightness

Colin Chapman, who founded Lotus, had one rule for building racing cars: "Simplify, then add lightness."

I have loved that line for as long as I can remember. Part of that is racing, a world I enjoy. Part of it is the absurdity. Lightness is the one thing you can only add by taking something away. Mostly, though, it describes how I approach problems, in software and everywhere else.

Look at the order. Simplify comes first, and lightness is what you get once you have taken away everything the car does not need. Chapman is also credited with this: "Adding power makes you faster on the straights. Subtracting weight makes you faster everywhere."

Software works the same way. A new feature helps on one straight. Less complexity helps on every lap, because everything you do afterwards gets a little easier.

Everyone agrees, almost nobody does it

Nobody argues for complexity. Ask any engineer and they will tell you simple is better. Yet most of the systems we work in are not simple.

That is because complexity rarely arrives as one bad decision. It arrives as a series of reasonable ones, such as a flag for one customer or a workaround that was meant to be temporary. Each one makes sense on its own. Together they make a system nobody fully understands.

So here is the irony. Keeping complexity at bay is one of the most complex things you can do.

AI has made this much worse. Each workaround, temporary fix or small request used to cost someone real effort, and that cost acted as a brake. Now we can ask an AI to patch it in, so the barrier is far lower and systems become complex much sooner than they did before. It is a double-edged sword, though. With the right instructions and monitoring, AI should also make it easier to refactor that complexity back out.

Worse is better

I only recently came across "The Rise of Worse is Better", an essay Richard Gabriel wrote in 1989. I had never read it before, but it spoke to me straight away, because it puts into words something I have long believed.

Gabriel compares two schools of design. Both value the same four things: simplicity, correctness, consistency and completeness. The difference is only the order. The first school, "the right thing", wants a complete, consistent design with a simple interface, however hard it is to build. The second, "worse is better", puts a simple implementation above everything else. It will leave out the rare cases rather than make the system harder to build.

His point is that the second school wins. Early Unix and C did perhaps half of what people wanted, but they were small and easy to port. So they spread everywhere, and then people improved them. The complete designs took so long that they arrived too late.

What Gabriel describes is choosing what to leave out, so that what you build stays small enough to finish, understand and change. He adds a caveat that people often forget: the simple version still has to be basically right.

Gabriel himself never settled the question. A couple of years later he attacked his own essay under a pen name, and then published a reply to that attack. In 2000 he wrote papers for both sides of the same debate, and said he still could not decide. Even the person who named the idea found it hard to hold onto.

Why it is hard

If simple is better and everyone agrees, why is it so hard?

Because adding is visible and saying no is not. A new feature has a demo, a ticket and a person who asked for it. Nobody thanks you for the code you did not write, and we are never rewarded for inaction. Often the right answer is to say no.

Knowing that does not make it easy, and saying no is something I really struggle with. The hardest case is a request that is perfectly reasonable. I have a gut feeling, built on experience, that the complexity is not worth it, but I find it hard to say why. A gut feeling is a weak argument against a reasonable request, so the request usually wins.

This goes deeper than software. In Subtract, Leidy Klotz shows that when people try to improve something, they tend to add to it and rarely think to take anything away. We are wired to add.

Because simplicity does not stay done. Like weight on a race car, things get added every season, and someone has to keep taking them away.

And because simple is not the same as easy. Easy is what is close to hand, like the quick fix or the extra parameter. Simple is what has fewer parts when you have finished. Getting there usually takes more thought. Rich Hickey makes this point far better than I can in his talk Simple Made Easy.

Too light

Chapman's cars were fast. They also had a reputation for breaking. Fans joked that Lotus stood for "Lots Of Trouble, Usually Serious".

That is Gabriel's caveat again. Strip out too much and the car does not finish the race. The aim is the lightest system that still does the job.

Back to the garage

Keeping things simple is hard. We all struggle to keep complexity at bay, and we all lose sometimes. But it is the good fight. Every unnecessary thing we remove leaves less to understand, less to maintain and less to get in the way of the next change. The work is never finished, but it is worth doing.