In the 1997 movie "Contact", Jodie Foster discovers an alien signal that contains the construction plans for a spaceship. Trying to assemble it, the engineers are surprised to find that the crew capsule is just an empty metal pod.

“That shit’s unsafe”, they say (I’m paraphrasing), so they attach a complicated wall-mounted seat to the inside. When the ship launches, that seat starts to pick up heavy vibrations and violently breaks apart. Foster releases her seatbelt seconds before it kills her and ultimately finds that the design was perfect all along, enjoying the rest of the ride in smooth anti-gravity.

We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process we create another layer of complexity that, in turn, causes its own set of issues.

Simplicity as a Feature

Permalink to “Simplicity as a Feature”

Obviously not every problem has a simple solution, and most complex tools exist because of real usecases. But I think there’s a lot of value in actively questioning the need for complexity. Sometimes the smarter way to build things is to try and take some pieces away, rather than add more to it.

Static sites are on the rise again now, precisely because they are simple. They don’t try to manage serverside code with clever abstractions - they don’t have any. They don’t try to prevent security breaches with advanced firewalls - they get rid of the database entirely.

Some of the most important things in the world are intentionally designed “simple”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.

Think for Yourself, Question Complexity

Permalink to “Think for Yourself, Question Complexity”

Developers are obsessed with the notion of “best practice”.
It implies that there is one correct way of doing things, and all other solutions are either imperfect or, at worst, “anti-patterns”. But the definition of best practice changes everytime a new technology arises, rendering the previous solution worthless garbage (even though it still gets the job done).

There is an undeniable ego factor to the way we use technology in our projects. To show everyone else how clever we are, we come up with harder and harder ways to achieve our tasks. And of course they all solve specific problems - but that does not mean they are always the best solution, regardless of context.

It’s cool to use the latest and greatest tech; but we should always ask if our choices really benefit the user, or if we do it mostly for ourselves. After all, the “Developer Experience” is only a means to an end.

And if we’re talking DX - I’ll take simplicity over features any day.