Image for post
Picture by me

This essay first appeared in Gray Matters** 🧠, **a weekly newsletter I co-write with Mario Chamorro where we discuss Productivity, Tech, the New Normal, and everything in-between. Pleaseconsider subscribing if you like this essay.


I personally contend with a lot of complexity in my job as a software developer, mostly thinking about “where” to put it: is it better to spend time now to make the code less complex for future changes, or is it ok to leave it as it and we can deal with the complexity at a later time if needed? It’s a question without a good answer, as it depends on a bunch of externalities you have no control over: will we maintain this feature for years to come? will it require constant tweaks? All this to say that someone at work recently posted about the Law of Conservation of Complexity which states that complexity can only be moved but not eliminated, which poses the question of…


[…] who should be exposed to the complexity. For example, should a software developer add complexity to the software code to make the interaction simpler for the user or should the user deal with a complex interface so that the software code can be simple?

Bruce Togazzini has a bold answer to that question: you shouldn’t think about that, but about what happens when we — software developers — inevitably hide complexity inside the applications (i.e. make applications more powerful but simpler to use):

If people will insist on maintaining equal complexity, yet we reduce the complexity people experience in a given task, people will take on a more challenging task.

In other words, the more complexity we hide inside the applications, the simpler they are to use, and the more complex tasks the users will want to perform.

Given that people will continue to want the same level of complexity in their lives, given that we will continue to reduce the proportion of complexity of any given function that we expose to the user, we may expect that the difficulty and complexity of our own tasks, be they at the application or OS level, will only increase over time.

Image for post

In the previous chart (via) we can see Togazzini proved right: there is an exponential explosion in the Lines Of Code (LOC, which we can use as a proxy for complexity) in commercial aircraft systems as time goes on. Pilots have now an easier time interacting with the systems, which frees up their “complexity reservoir” to take on more complex tasks.

Slack is another perfect example. Most of the people I talk to don’t realize that the apps that look the simpler to use are in fact the most complex to build because all the complexity they don’t experience as users is contained inside the code. If you ever catch yourself thinking** “it’s easy to use, therefore it must be easy to build”**, try to remember that if you as a user are not experiencing the complexity, someone must have dealt with it for you :-)

#user-experience #software #coding #apps #software-development #visual studio code

Why Easy-to-Use Apps Are Complex to Build
1.15 GEEK