What Makes Software Good?

This post asks what makes software good, argues that the usual answers rest on opinion, and offers a firmer ground: what the user perceives. It then summarizes the philosophy I call Empirical Software.

The question

We have been given many answers:

• It should be modular.
• It should be loosely coupled.
• It should follow SOLID principles.
• It should use the right design patterns.
• It should have high test coverage.
• It should be “clean.”

Do these metrics guarantee good code?

How do you know when to stop decoupling? How much modularity is enough? When does a pattern become a burden? When does “clean” become a labyrinth?

These metrics are opinions and preferences. They come from people who built successful systems, and that wisdom is useful, but wisdom is not the same as truth.

Solutions are relative

Like many things in this world, software solutions are not absolute. They are relative to a reference frame.

In one frame a solution is well crafted. In another it is a disaster. A system that works perfectly for a small startup can collapse under the weight of a large enterprise. A system that is elegant in theory can be unworkable in practice.

So how do we choose the reference frame? Personal preference? The team’s opinion? An architect’s imagination? A senior engineer’s authority?

If so, we are not in a good place. An opinion is still an opinion when it comes from someone who has built successful projects. Authority does not make something true. It only makes it authoritative.

The problem with authority

A firm ground should depend on reality, and not on us.

Software is a lot like philosophy here. Philosophy is not true because Aristotle or Hegel said it. It is true when it is honest and grounded.

The same applies to software. A system is not good because an authority says so. It is good because it corresponds to something real: it serves a real purpose and communicates a real experience to a real person.

The philosophical root

I apply the rigorous critique of the empiricists to software.

I agree with Berkeley that if we ground our thinking in opinions or imagination, we produce elaborate metaphysical labyrinths and nothing that corresponds to reality.

So we need to dereify: stop treating abstractions as if they were real things, and stop building ghosts. And we need to ground ourselves in perception.

The screen is the ground

What is the ground of software?

It is what the user perceives: the screen, the buttons, the forms, the status messages, the results.

Everything else, meaning the code, the architecture, the database and the framework, is machinery. It supports the software and implements it, and it could be different. Philosophers call this an accident.

This is a description of how software is used, and not a matter of taste. The user does not see your architecture, your database or your code. The user sees the screen. That is the ground.

What Empirical Software offers

Empirical Software is a philosophy of building software that is grounded in reality. It says:

• Ground everything in perception. What the user sees is the only reality that matters.
• Distinguish substance from accidents. The substance is what the user perceives. The accidents are the machinery that delivers it.
• Protect the substance. Keep it pure, testable and soft.
• Treat accidents as swappable. Change them freely and replace them without changing the substance.
• Refuse the status trap. Complexity is not competence. Simplicity is not naivety. Clarity is strength.

An invitation

I invite you to stop building ghosts, to stop accepting the gaslighting, and to stop pretending that complexity is a sign of seriousness. I invite you to start building substance, grounding everything in perception, and building software that is truly soft.

The truth is on your side. If this appeals to you:

• Join the community. Connect with others who are building grounded software.
• Learn the principles. Study the difference between substance and accidents, and the practice of grounding in perception.
• Apply the philosophy. Start building software that is soft, grounded in what the user perceives.

The screen is the ground. The user is the reality. The code is machinery.