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!