What Makes Software Good?

An Introduction to Empirical Software

I. The Question

What makes software good?

We have been told 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."

But 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 not absolute. They are opinions. They are preferences. They are the accumulated wisdom of people who have built successful systems—but wisdom is not the same as truth.

II. The Relativity of Solutions

Just as many things in this world, software solutions are not absolute.

They are relative to a reference frame.

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

But how do we choose the reference frame?

Is it personal preference? Is it the opinion of the team? Is it the imagination of an architect? Is it the authority of a senior engineer?

If that is the case, we are not in a good place. An opinion is still an opinion, even if it comes from someone who has built successful projects. Authority does not make something true. It just makes it authoritative.

III. The Problem with Authority

Real ground should not depend on us.

It should depend on reality.

Software is very similar to philosophy. Philosophy cannot be true because of some authority—like Aristotle or Hegel—but by the virtue of being honest and grounded.

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

IV. The Philosophical Root

In our philosophy of software, we apply the rigorous epistemological critique of the empiricists.

We agree with Berkeley: if we ground our thinking in opinions or imaginations, we will produce elaborate metaphysical labyrinths—not something that corresponds to reality.

We need to dereify. We need to stop treating abstractions as if they were real things. We need to stop building ghosts.

And we need to ground ourselves in perception.

V. The Screen Is the Ground

What is the ground of software?

The ground is what the user perceives. The screen. The buttons. The forms. The status messages. The results.

Everything else—the code, the architecture, the database, the framework—is machinery. It is support. It is implementation. It is accident.

This is not an opinion. This is a recognition of reality. The user does not see your architecture. The user does not see your database. The user does not see your code.

The user sees the screen. That is the ground.

VI. 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. Keep it testable. Keep it soft.
Treat accidents as swappable. Change them freely. Replace them without changing the substance.
Refuse the status trap. Complexity is not competence. Simplicity is not naivety. Clarity is strength.

VII. The Invitation

We invite you to join us.

To stop building ghosts. To stop accepting the gaslighting. To stop pretending that complexity is a sign of seriousness.

To start building substance. To start grounding everything in perception. To start building software that is truly soft.

The truth is on your side.

VIII. The Action

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

This is Empirical Software.

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

Join us.