What Would Albert Camus Think About Software Development?

🌱 This blog post hasn't fully bloomed. It's very likely to change over the next little while.

Albert Camus was a French philosopher most well known for his ideas about absurdism.

Sometimes regarded as an existentialist philosopher among his peers like Jean-Paul Sartre and Simone De Beauvoir, he contemplated existence, the complexity of the world, and eventually declared that any meaning we find in the world is there because we have personally assigned it.

As software developers, the very essence of what we do is to create something productive and meaningful within the inherent entropy of the world.

As Julian Shapiro says, the world is a patchwork of systems. And in the real world, we are constantly clashing against complexities. We maneuver though clumsy incumbent systems like "making friends in a new city", "finding an apartment that suits our needs", and "getting our driver's licenses renewed".

Software cuts through this complexity. We help people get from A to B with less stress, less effort, faster, and easier.

But not all complexity is equal. In our attempts to cut through complexity, we often create complexity.

I imagine that if Camus were a software developer, his famous quote about suicide could be reworked to say:

"There is but one truly serious philosophical software design problem and that is maintainability. Judging whether code is maintainable or not amounts to answering the fundamental questions of software design. All the rest — whether we should use React, a hexagonal architecture, server-less functions — comes afterwards. These are games; one must first answer."

Our mission with software design (as we discuss in the introduction of solidbook) is fundamentally to implement these two high-level goals - one for users and the other for developers. If we're not doing both well, our software design attempts are failing.

• 1. [Users] Satisfy the needs of the user
• 2. [Developers] Do it in the most maintainable way possible

The first goal is accomplished by implementing the essential complexity, that is - the features. If it were possible to use a no-code builder to reliably do this every time, then we'd likely be doing that. However, that's not where we are as an industry, so we write code to realize systems that solve problems for people.

The second goal exposes surface area for accidental complexity. We need to use paradigms, languages, and tools to build software. Some of these introduce inherent concepts that are known to cause (like state and sequence, according to Ben Moseley in his influential "Out of the Tar Pit" paper), and some of them introduce other subtle forms of complexity like:

• Cognitive load
• Ripple
• Poor discoverability
• Poor understandability
• and leaky abstractions

It's for this reason that I'm starting to believe, more and more, that aligning with the essence of the problem should be the school of thought to which we master software design.

I believe that we should seek out techniques that bring us asympotically closer to implementing the bare minimum - the essential complexity of the problem - and mitigates as much accidental complexity as possible.