Not long ago, I was browsing through a stack of old foreign technical magazines when I stumbled upon an article that immediately caught my attention.
Its author discussed programming with such ambition that it felt like reading an attempt to write a “Periodic Table of Software” - a universal framework for code.

Judging by the tone, the author was inspired by the ideas of Norbert Wiener, the father of cybernetics.
Yes, the same mathematician who proposed that both biological and technical systems could be described through feedback and control mechanisms.
The author seemed to apply that logic to programming itself, outlining a concept that could be described as the General Theory of Programming, or simply GTP.

To be clear from the start: no such formal theory actually exists in computer science.
But the ideas presented in that forgotten text - or perhaps imagined through retrospective interpretation - sound surprisingly modern.
In many ways, they anticipate what we now call Domain-Driven Design, software architecture principles, and convention over configuration.

The Core of the “General Theory”

The main goal of the so-called General Theory of Programming is to identify the principles that help us make good engineering decisions - not just decisions that “work,” but those that remain maintainable, predictable, and scalable over time.

At first glance, this sounds abstract, but so did most of today’s software philosophies when they first appeared.
In essence, GTP doesn’t prescribe specific rules - it tries to describe why good solutions tend to resemble each other, while poor ones fail in familiar ways.

The author defined several “aspects,” the first of which remains as relevant today as ever.

The First Aspect - The Dictate of Agreements

The simplest way to summarize it is:

“Good systems are built on agreements.
Bad systems are built on accidents.”

If you look closely, everything in programming is a matter of agreement:

Protocols (like HTTP) are agreements on how data is transmitted.
Interfaces are agreements on behavior and state.
Programming languages are agreements between humans and machines on what code should look like.
Architectural styles, formats, and design patterns - all are forms of agreements.

In short, the entire software world is one vast network of conventions.

Why Linux Works While “Clean Code” Keeps Arguing With Itself

Take the Linux kernel, for example.
If you open its source code, you’ll find plenty of “magic numbers” and constructs that would make a Clean Code enthusiast raise an eyebrow.
And yet, Linux runs billions of devices and remains a cornerstone of modern computing.

Why?
Because within that community there is a clear internal agreement, and everyone abides by it.
Returning 0 instead of a named constant isn’t considered a problem - it’s part of the convention.
As long as the team consistently follows its own rules, the system remains coherent.

The real chaos begins when there are no shared agreements, even if the code looks perfect on paper.

When Agreements Collapse

The classic counterexample is JavaScript and the browser ecosystem.
There’s a formal specification, sure - but for years, each browser interpreted it in its own way.
The result: inconsistent behavior, endless compatibility issues, and the legendary typeof null === "object".

The underlying reason is simple: a lack of strict adherence to common agreements.
When everyone does things “almost the same,” the differences eventually become catastrophic.

The Practical Meaning of the Dictate of Agreements

The lesson here is straightforward:

Agreements should exist everywhere - and they should be binding.

That includes:

a unified domain language (hello, Domain-Driven Design),
a consistent coding style and naming conventions,
architectural principles and design constraints,
and clear communication protocols between teams and systems.

And, as the original author would probably say, all of these agreements must share two properties:

Mandatory compliance.
A single source of truth.

When those two conditions are met, chaos retreats - even if the code isn’t perfect.

A Bit of Philosophy

If we treat the General Theory of Programming not as a literal discovery but as a metaphor, it beautifully captures what software engineering has been trying to do for decades.

We constantly reinvent ways to tame chaos - new patterns, methodologies, architectural styles, and testing paradigms.
All of them, at their core, are just new layers of agreements between humans and machines.

So perhaps there never was an official “General Theory of Programming.”
But the idea that programming is the art of agreement sounds like a theory worth keeping.

If Norbert Wiener could see modern software development, he’d probably smile and say:

“Now you finally understand - systems run not on code, but on consensus.”

TL;DR

The “General Theory of Programming” is fictional, but conceptually sound.
Everything in programming is built on agreements.
The stricter the agreements, the more stable the system.
Linux succeeds through internal coherence; JavaScript once suffered from the lack of it.
Maybe the true “theory of everything” in IT isn’t perfection - it’s alignment.

mediaquest

mediaquest