Describing vs Creating a Thing

What I’ve loved since the first day I discovered programming, is that it is an endless opportunity to create.

What has become more and more apparent over the intervening three decades, is that language is a terrible place to make the source of those creative ideas.

This is why I think “source code “is a terrible place to put software. More specifically, it’s a terrible place to put decisions about software.

The reason for this is that we are restricted to describing the thing, and to do this we first have to pick a specific language.  Anyone who doesn’t speak that language is going to struggle to understand what is being described. Put two or three languages in the same room, and the problem gets exponentially worse.

For computers offer us an opportunity that is inaccessible without them, and that is the ability to literally create an instance of what is being described, in about the same time as it takes to describe it.

This digital instance of the idea, this digital twin, serves as a language-independent definition of reality for the project. In other words, if the digital twin is a mockup of the app, anyone should be able to use the app and understand the idea implicitly. Not because they read a well written description of the thing, but because they can literally interact with an instance of it directly. 

With that understanding, they should be able to request various development assets, in a specific technical context, that can be unambiguously interpreted to provide a layer of derived code based directly on the digital twin.

So if a widget in the project has a name, Date of manufacture, and serial number, our digital twin had better also have widgets, with a name, date of manufacture, and a serial number.

In fact, ideally widgets would have those three attributes anywhere that they exist within the system including the specifications, the backend code, the front end code, any test infrastructure, documentation, etc.

Each of those places will describe, in whatever language they are using, this widget again. Over and over and over again.

So when the notion of ‘what a widget is’ changes in any way, all of those different descriptions have to be updated to describe a now slightly modified widget.

But the reason I called the digital twin a single source of truth, is that with a single source of truth (as the name implies), we only have to update the notion of what a widget is in one place. 

And having updated the template example of what a widget is, it then becomes very easy to use that template to describe the widget in English, and C-sharp, and Python, and Java, etc.

If we don’t have a single, authoritative, template example of the idea, every time the idea changes our only option is to laboriously go through pages and pages of the English description, and tens or potentially hundreds of thousands of lines of code, to try and realign those descriptions with the new rules.

This is an exercise in futility. It would be like a world without sheet music!

Imagine a world without sheet music!

 Imagine a world where sheet music has never been invented.

Instead, each instrument has its own language, specifically designed to describe exactly how to play a specific song, on that specific instrument.

So violin music, would be in a different language than piano music, which would be in a different language still than flute music.

The implications of this are hopefully clear. If we had an orchestra and wanted to add a flute, playing exactly the same thing as the violin part, we should first have to hire a human being who knew both flute and violin Music, who could translate the music from one to the other. 

This kind of translation would be necessary anytime the composer changed the music when it is actively being developed.

This is obviously absurd, and I hope that no one would advocate for such a model.

And yet…

It seems to me that is largely the world that we live in when it comes to technology. There is absolutely nothing that is equivalent to sheet music in the tech industry!

Just to be clear, I am NOT suggesting some kind of universal language. I think that’s equally, or possibly more absurd than a world without sheet music, insofar as people have been trying to create such a language for 70 years and have failed entirely.

AI is the one obvious and notable exception to this, as eventually, AI will be able to simply take an English prompt for a program and give us code that does that. We are not there yet, but we’re getting pretty close.

But again… to be clear, I am definitely not talking about a linguistic description of some app or service - because that's not what sheet music does.

Sheet music just describes an abstraction of the song. It does not describe how to play that song on any particular instrument, and rather provides information that is going to be true about the song completely independent of which instrument it is played on.

It essentially just tells you the frequency and duration of each note that needs to be played.

The equivalent of sheet music in technology is a normalized, multi-dimensional, data-based, non-linguistic instance of the idea itself. 

Literally, at the end of the day, it’s just a database. 

At runtime, it will typically present as a json or xml configuration file, for example, but the source of it should be a relational database such as Airtable or SQLonAir.com.

The reason is that in Airtable, for example, we can create a language independent digital example of whatever is being described, at virtually the speed of speech. In other words the digital example can be created approximately as fast as that thing can be described in English.

And that thing could literally be ANYTHING. It could be an app. It could be a website or online service. It could be an organization, nonprofit, or other business venture. It could be a philosophical discussion about the nature of reality. 

The essential structure of *any* idea can be unambiguously constrained and defined by a normalized database representation of the idea, including detailed calculations on said data with lookups, aggregations and calculated fields.

This digital twin then, immediately and unambiguously, removes the idea from each of the participants' heads, to an external shared location (in the cloud) that everyone can either agree or disagree with, about how closely it does or does not line up with their understanding of the idea.   

What this addresses, is that without it, everyone has this model in their own head, and they assume that everyone else shares the same model.

But they don’t.

In reality, without a shared single source of truth, everyone’s model is going to be slightly different, and it’s like a big long game of telephone trying to communicate to understand how each person's understanding does or does not line up.

This underlying, language based approach is fundamentally broken at its core.

If the English description is essentially just reporting on the current state of the digital example of the idea, then anytime we change the digital instance, adding a model number, for example, We can immediately expect the English to be up-to-date because it is simply reporting on the state of the instance, and the instance now has a model number.

In the same way we can expect any code which has been written about widgets to also be updated, because their internal representation of widget should not be defined in that “source code”, because the python isn’t the source – the digital example we created is the source, And any linguistic description of widget, in any language, whether human or machine focused, should be directly derived from the digital twin so that all the linguistic descriptions simply “follow along” as the idea changes over time.

We know change is gonna happen, so let’s plan for it.