Reading Maeda’s Laws of Simplicity in my twenties had a profound impact on me. Law 1 (Reduce) has been beneficial over the years as I think about UIs and experiences. Learning how to reduce complexity is probably the biggest skill you can learn in your career in UX, accessibility, performance, and even development as a whole. If you don’t need it, remove it.

Conversely, in recent years I’ve begun to understand Tesler’s Law of Conservation of Complexity which admits some of the shortcomings of reducing. While making consistent user interfaces at Xerox PARC in the early eighties, Larry Tesler observed:

Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.
— Larry Tesler, Designing for Interaction (2006)

After you hit the wall of unremovable complexity, any “advances” are a shell game, making tradeoffs that get passed down to the user. If you have too many links in your main navigation, you hide those links in a dropdown, and pass the cost of an extra click down to the user. In Tesler’s days there was tension between the server and the user and because servers were slow and hard to program, a lot of the interface complexity ended up passed to the user.

If that sounds a lot like modern day Front-end Development, you already see where I’m going with this. Not much has changed since Tesler’s day, code runs on either the client or the server. Thankfully today we have a few more levers to pull like “The Edge”, but the principle still applies; you get “advances” by shifting where the complexity lives. There’s good technical nuance, but most of the web’s fresh #hotdrama gets reduced to this for me.

What’s your CSS style scoping method? Past experiences probably informed that decision but I see it as passing the complexity between technologies.

See the Pen How are you managing scoped styles? by Dave Rupert (@davatron5000) on CodePen.

You like using <Spacer/> components? I get it, I’m fond of them too. Are you diametrically opposed? I get that perspective too, the burden of empty divs littered everywhere can add up. There’s drawbacks to everything.

See the Pen How are you managing spacing? by Dave Rupert (@davatron5000) on CodePen.

Tradeoffs. Passing complexity. I can’t unsee it. In fact, it’s all I see sometimes. And I’m sure my Jim-from-The-Office face comes out in a meeting when someone claims there are “no drawbacks” to a given approach. O, to possess that ignorance again.

Further complicating the issue, I don’t believe people (myself included) are rational decision makers. We don’t really make software architecture decisions based on some rigorous cost/benefit analysis. Decisions are often more informed on existing biases, past experiences, and the tradeoffs people find most comfortable. Decisions also get slipped in under the cover of self-imposed sprint deadlines or get made using a “Loudest Person Wins” system. Sometimes, it seems, the act of making a decision or the need to “unblock” something gets elevated over the impact of the decision.

I think this is where the second implication of Tesler’s Law comes into play: “Who will inherit the complexity?” Is it a value or a cost that gets passed on to the user? It’s a simple question, but the answer dictates so much. I also think when answering “Who will inherit the complexity?” it’s important to also ask “Are we considering users that aren’t wealthy, western, affluent, and able-bodied?” Answering that second question, shines a light on our answer to the first.