Full Interview Transcript

How does the Business Rule Completeness Conjecture relate to time?

Are you suggesting that Syntax-Locking is not just error prone, but that it also necessarily introduces time into the equation, and that if we use the kind of declarative model suggested by BRCC that time would largely vanish?

Yes!

Alright... imagine this scenario like a classic game of "telephone", but not just with people, with entire systems, languages, and roles. Here’s how it goes.

You start with a business rule.

A stakeholder, let's say a product manager, has a clear conceptual idea in their head. It’s this rich, multi-dimensional, nuanced mental model.

So if we think about the main character in Edwin A. Abbott's Flatland, square, when it flips out of the title's flat land, into space land, it was able to consieve of the entire sphere in the blink of an eye.

And keep in mind, that this would be true, pretty much regardless of how big it was.

The stakeholder's idea, while still in their brain is like the 3D sphere in "Spaceland."

They can see it, feel it, and understand it all at once, navigating even complex ideas naturally.

But here’s the problem, then they have to communicate it.

And when they do, it is going to be much closer to square's experience of that exact same sphere when in flatland.

Most problematically in fact is that flatland necessarily introduces time.

Think about that for a second.

In spaceland, it can be consumed all at once, where the exact same sphere takes time to pass through flatland.

What this means is that it's not even just time, but the time will be pretty directly correlated with the size of the sphere.

Bigger sphere, more time.

And the only tool that the Stakeholder has in a traditional model is syntax. Maybe they write it down in English as a user story. Instantly, something fundamental is lost.

They’ve just flattened a sphere into a series of circles of different sizes, or worse, into a line of text. It’s no longer the full 3D model, it’s a linear, sequential, and fragmented slice of the whole idea.

Next, the developers get that story.

They have to interpret it and lock it into yet another syntax, maybe Jira tickets, requirements docs, or acceptance criteria.

The sphere is flattened again, now it’s a line on a Gantt chart or a bulleted list.

Then the developers write code.

This is where the conceptual model takes its hardest hit. Now, it’s squashed into Python, Csharp, or sequel.

The sphere isn’t a sphere anymore.

It’s an even narrower abstraction, fully locked into the quirks and constraints of a specific programming language.

The language has its own rules, loops, functions, and variables... none of which existed in the original mental model.

Then comes QA.

They don't see the original model.

They don't even see the user story as it was first written. They see tests, assertions and conditions written in still more syntax.

Each test case is like another flattened slice of the sphere, only visible in narrow frames, like a security camera with blind spots.

Then, documentation.

Another flattening.

Someone writes a user manual or API docs.

Yet again, everything is re-flattened into a new language, maybe plain English this time, but still a description, a shadow on the wall of the cave, not the 3D object it was meant to reflect.

But here’s the kicker.

One day, the stakeholder realizes the rule needs to change.

Maybe the original sphere had spikes, but nobody saw them because they weren’t in the flattened circle.

Now, you have to reintroduce that change everywhere. Back to the user stories.

Back to Jira. Back to the devs. Back to the code. Back to QA. Back to the docs.

Every single artifact is instantly out of date.

It’s like playing telephone with ten different languages at once, each with its own quirks and constraints.

You’re constantly unlocking and re-locking the knowledge at every step, and each time, you lose a little fidelity.

Each unlock costs time, like the square in Flatland watching the sphere pass through his world one slice at a time.

The same sphere that could be understood instantly in 3D takes hours, days, or weeks to reassemble in Flatland.

This is the problem with syntax-locking.

So, what’s the alternative?

The alternative is syntax freedom.

It’s like holding a high fidelity digital mirror to reality.

Instead of flattening a sphere into a series of slices, you build a system that just holds the sphere as-is.

You don't convert it to Python.

You don't flatten it into Jira tickets. You don't "explain" it in natural language documentation. Instead, you maintain it in a system like Airtable, Baserow, or a conceptual knowledge graph.

A system like Airtable lets you work with lookup fields, rollups, and calculated fields, which operate on conceptual models directly, not on Python loops, sequel joins, or Jira workflows.

It stays a high-fidelity mirror of the real thing.

And if the stakeholder realizes the sphere has spikes, guess what?

You add a spike. Instantly. You don't rewrite user stories. You don't rewrite QA tests.

The mirror updates in real-time, and the vast majority of the reflections update automatically.

This is the difference between working with the model itself (the sphere) versus working with descriptions of the model (the circles, the lines, the Jira tickets, the code, the docs, and the tests).

If you imagine playing a game where you describe a picture to someone who is attempting to draw it?

Well, you can imagine the problems that are likely to arrise.

It’s always going to be faster to just show them the picture.

The reason this matters is simple: time and complexity.

Time is injected every time you have to flatten, reformat, re-explain, and update. It’s why waterfall processes failed, because every stage was a flattening event.

It’s why Agile was supposed to help, but in reality, it just turned every sprint into a series of micro-games of telephone.

We’ve gone from Big Waterfall to Mini Waterfalls but the same flattening is happening every day, just in smaller increments.

The entropy is still there. The complexity grows with every layer of syntax.

And this isn’t just a software problem. It’s a linguistics problem at the end of the day.

In linguistics, they conflate "conceptual models" with "syntax."

They look at a UML diagram and say, “This is concrete syntax.”

No, it’s not. The diagram is the milk.

The UML code (the XMI, the PlantText) is the cream.

The milk is a conceptual, syntax-free, language-agnostic mirror of reality.

The XMI is a syntax-locked, language-dependent flattening of that milk. Don’t confuse the milk for the cream.

Linguists treat them as the same.

And that, right there, is the category error at the heart of linguistics and software design, at least from my perspective.

Here’s the punchline:

The stakeholder has a sphere. The dev sees a circle. The QA sees a line. The docs see words.

But the sphere was always the same.

You could have held it up in a mirror for all to see, in 3D, all at once.

No need for translation, flattening, or relocking the same knowledge a dozen times.

This is why syntax locking is the root of all evil, and syntax is the devil.

It locks knowledge into specific, constrained languages.

Syntax-locked knowledge can only be seen through one keyhole at a time.

But Syntax-free knowledge is like having the whole house with all the doors open at once.

The world of business rules, development, and QA will continue to struggle as long as we work with flattened projections of reality instead of holding up mirrors to reality itself.

The solution isn't to "get better at Jira" or "write better specs."

The solution is to stop flattening the sphere. Keep it in its original form as long as possible. Start with pre-syntax.

End with syntax only at the last possible moment. In this way, you eliminate most of the entropy, most of the rework, and most of the "game of telephone" delays.

This is how Airtable can achieve in minutes what takes traditional tools weeks.

Because Airtable, Baserow, and conceptual knowledge graphs are mirrors of reality, not descriptions of it.

So, what’s the moral of this story?

Stop flattening spheres. Stop feeding the syntax devil.

Hold up a mirror instead, with a BRCC compliant rulebook, so Tee me and EffortlessAPI.