Why do we create software?

Let’s start with a "simple" question: why do we create software?

Humans pursue knowledge for two reasons: curiosity and solving problems. Sometimes they mix. You try to fix something and end up loving the learning. But for this reflection, let’s focus on the problem-solving part.

Every project we work on — personal or professional — starts with a problem. We try to automate boring stuff, prevent incidents, save time, improve accuracy, do what was previously impossible, coordinate people and processes… Basically, we try to make life a little easier.

In other words: software exists to reduce friction between what we want and what actually happens.

Sounds simple enough. But then… why does software so often make things worse? Why does it confuse people, break randomly, frustrate users, or make future work a nightmare?

Not because engineers don’t care. Not because the business is “evil”.

It happens because motivations aren’t fully aligned. Speed is easy to measure, maintainability isn’t. Shipping is visible; technical debt is invisible. Software feels reversible — like you could just CTRL + Z it later.

Spoiler alert: you can’t. Complex systems remember. Decisions pile up. Mistakes compound.

And yet, people still talk about “quality” like it’s a purist argument:

“The good practices say…”

Sure. But here’s the simpler truth: if we create software to solve problems, anything that introduces instability, fragility, or long-term friction is incomplete.

A complete solution:

• Works correctly
• Handles functional and non-functional requirements
• Remains understandable
• Can evolve as needs change

Anything less? It’s not done. It’s just shipped.

Quality isn’t a fancy ideal. It’s purpose realized.

And if we forget why we create software in the first place… well, don’t be surprised when it stops solving the problem.