One of the most curious — and perhaps most uncomfortable — things about software engineering is that we still make many important decisions on grounds that are far too fragile.

Of course, we rarely call this an “unfounded decision.”

We prefer better names:

Strategy.
Transformation.
Modernization.
Best practice.
Vision for the future.

But, quite often, beneath these elegant labels, there is something less noble: imitation, enthusiasm, market pressure, personal preference, or the comfortable belief that what sounds modern must also be correct.

And this should concern us more.

Software is no longer a peripheral tool. It sustains banks, hospitals, logistics, governments, communication, retail, industry, and a large part of everyday life.

When a bad decision is made in software, the cost does not appear only as technical debt or as a confusing architecture diagram.

It can turn into operational fragility, wasted investment, loss of trust, unnecessary dependency, and real business risk.

And yet, for a field that likes so much to call itself engineering, we tolerate an impressive amount of decisions that, when seen up close, look more like well-presented improvisation than engineering itself.

In theory, we are disciplined.
In practice, we are often just articulate.

When evidence is missing, something takes its place Link to heading

That is why the idea of evidence-based software engineering seems so important to me.

The premise is simple: decisions about development, maintenance, architecture, and modernization should combine three elements:

  • the best available evidence;
  • the practical experience of professionals;
  • the values and constraints of the context involved.

It is not isolated research.
It is not isolated experience.
It is not isolated intuition.

It is the serious combination of these dimensions.

It sounds obvious.

But if it were truly obvious in practice, our industry would make very different decisions.

Because when evidence does not occupy enough space, other things do.

And they are rarely neutral.

The first substitute is hype Link to heading

Hype is powerful because it rarely presents itself as hype.

It appears as inevitability.

“The future of software.”
“The new way to build.”
“The architecture everyone is adopting.”
“The tool that changes everything.”
“The process modern teams use.”

For those who are starting in the field, this is especially dangerous.

Not because of a lack of intelligence, but because the industry is very good at confusing novelty with legitimacy.

When an idea appears everywhere at the same time, repetition starts to look like proof.

But repetition is not proof.

A practice does not become solid because it dominates conferences, posts, commercial presentations, or job descriptions.

Sometimes, “best practice” is just preference with better marketing.

The second substitute is strong conviction Link to heading

This one is harder to perceive, because it often comes from competent people.

A senior engineer defends a method.
A respected architect believes in a pattern.
A leader saw something work once and starts treating it as a universal truth.

Experience matters a lot.

But experience alone does not become evidence just because it comes from someone experienced.

Without comparison, without contrast, without critical analysis, and without context, experience can turn into something much less useful:

elegant bias.

In software engineering, certainty is often socially rewarded long before it is intellectually deserved.

And that creates a problem.

We start confusing confidence in the discourse with quality of the decision.

The third substitute is adoption pressure Link to heading

Not every technology decision is born from a careful analysis of the problem, the alternatives, the risks, and the available evidence.

Sometimes, a technology is adopted because the organization feels behind for not having adopted it yet.

The market is moving.
Competitors are moving.
Leadership wants a modernization narrative.
Teams want to feel current.
Vendors are applying pressure.
The slides are ready.

Suddenly, the question stops being:

“Is this the best choice for our context?”

And becomes:

“How quickly can we say we are doing this?”

This is not engineering.

It is performance under strategic anxiety.

And software engineering is full of it.

The fourth substitute is market language Link to heading

This is perhaps the most dangerous one, because it sounds sophisticated enough not to be questioned.

We use expressions such as:

  • cloud-first;
  • AI-native;
  • future-proof;
  • enterprise-grade;
  • scalable by design;
  • industry standard;
  • ready for transformation.

Some of these terms may mean something real.

But many work as rhetorical shortcuts. They create the appearance of rigor precisely where rigor is missing.

And they spare us from harder questions:

Better for whom?
Under what conditions?
At what cost?
With what evidence?
Compared to what?
With which risks transferred to the future?

A sophisticated vocabulary can hide a fragile decision very efficiently.

The problem is not only changing too much Link to heading

Here the conversation becomes more uncomfortable.

Unfounded decisions do not appear only when we adopt new things too early.

They also appear when we preserve what already exists without sufficient examination.

Sometimes, an organization keeps systems, practices, and architectures for reasons as fragile as those used to justify premature adoption.

Habit disguises itself as prudence.
Familiarity disguises itself as reliability.
Fear disguises itself as strategic caution.

So the problem is not simply adopting too much.

It is also preserving too much without asking enough.

At one extreme, we idolize novelty.
At the other, we idolize survival.

Both can be intellectually lazy.

The central question is not whether we are changing or staying.

The question is: what is the quality of the reasons behind the decision?

Evidence does not eliminate judgment Link to heading

It is important to say: evidence does not promise certainty.

And any approach that promises absolute certainty in software should be viewed with suspicion.

Evidence does not eliminate judgment.
It does not erase context.
It does not automatically resolve trade-offs.
It does not replace experience.

But it imposes a higher standard of seriousness.

It forces us to ask questions we often skip:

  • What problem are we really trying to solve?
  • What evidence exists?
  • Is this evidence strong or weak?
  • Does it apply to our context?
  • What are we calling knowledge?
  • What is only fashion, fear, pressure, or preference?

These questions are not academic luxuries.

They are practical obligations.

They matter when choosing an architecture.
They matter when adopting a process.
They matter when modernizing a legacy system.
They matter whenever a decision redistributes cost, risk, fragility, and future options.

For those starting in the field Link to heading

One of the easiest traps early in a career is confusing confidence with truth.

The industry is full of people who sound absolutely certain.

But sounding right is cheap.

Maturity in software engineering does not begin with confident discourse.

It begins with better questions.

It begins with a healthy distrust of poorly supported conclusions.

It begins when you understand that not every popular idea is good, not every old practice is bad, not every novelty is evolution, and not every stability is wisdom.

You do not need to know everything to think better.

But you need to resist the temptation to treat every trend as truth.

What makes a discipline mature Link to heading

A discipline does not mature when it becomes faster at repeating what is fashionable.

It matures when it becomes less tolerant of decisions that are easy to defend rhetorically but difficult to justify intellectually.

Software engineering does not suffer only from a lack of innovation.

Sometimes, it suffers from something more embarrassing:

the quiet normalization of unfounded decisions.

Perhaps a real sign of maturity in our field is not to stop changing.

It is to change with more judgment.

It is to preserve with more awareness.

It is to adopt with more evidence.

It is to recognize that, in software, the most important question is rarely:

“What is the most modern technology?”

Very often, the most important question is:

“On what basis are we making this decision?”

And perhaps that is where software engineering truly begins to deserve the name it carries.