Foundational Algorithms

Search algorithms.

Sorting algorithms.

Graphs.

Today, increasingly, AI.

Decision trees.

Clustering.

Neural networks.

They solve difficult problems.

But they are not the first algorithms.

There is another layer that every software system rests upon.

The constitutions of software.

The algorithms that determine what the system is before anyone begins deciding how well it performs.

The nature of our profession makes these algorithms easy to overlook.

We enter systems whose foundations already exist.

The business already runs.

The product already exists.

The states have already been defined.

The relationships have already been established.

The system can already survive without us.

We are usually being invited to make it better.

Reduce latency.

Improve reliability.

Scale the infrastructure.

Build another feature.

Refactor the code.

These are valuable problems.

But they are optimization problems.

The deeper we go into optimization, the more it shapes how we think about algorithms.

Search faster.

Sort faster.

Recommend better.

Predict more accurately.

Foundational algorithms ask different questions.

What is this thing?

What states can it occupy?

Which states should never exist?

How does one state become another?

What relationships exist between the things inside the system?

Who has authority?

What should never change?

These are not optimization questions.

They are first-principles questions.

They are questions of definition.

Of ontology.

Of state.

Of relationships.

The answers to these questions are the skeletal structures that allow a system to exist at all.

The procedures that enforce these foundational definitions and state transitions are themselves algorithms. They determine not merely how the system behaves, but what behavior is possible in the first place.

After all, you cannot optimize what doesn't exist.

You need a road before you can identify the shortest path.

This is why invention and optimization are different disciplines.

Optimization begins with something that already exists.

Invention begins with the question of what ought to exist in the first place.

Neither is superior.

Every invention eventually demands optimization.

Every optimization depends upon an invention that came before it.

The mistake is believing they are the same activity.

They are not.

One asks,

“How can this become better?”

The other asks,

“What should exist at all?”

The second question is usually the lonelier one.

There are no benchmarks.

No existing architecture.

No accepted definitions.

Only first principles.

You are deciding the nature of the thing itself.

Everything that follows inherits those decisions.

Long before the first optimization algorithm is ever written.

That is where the work of invention begins.