Low-Code, No-Code, and why "Source Code" is a terrible place to put software

What if there were an entire layer of code simply missing from most "traditional" development projects?  What if software developers could be spending their time focusing on just a small, interesting, innovative fraction of today’s “source code,” while having the other 70-90% automatically derived directly from the Specification on their behalf, regardless of which languages or tech stack is involved?

What if the very term itself "Source Code" was in fact a deeply flawed mangling of two completely different things?   

Step 1 - Admitting that we have a problem!

As an industry, the problem starts with the very term "Source Code".  The name incorrectly implies that "Source Code" is actually the "source" for a given project ... but rarely is that actually true - which is why it belongs in quotes. 

The real source is, or rather should always be the "Specification," as determined by the ongoing, ever-changing specific needs of the business in question - i.e. the constraints, rules, inputs, user stories, features, wants, needs, etc - which are all subject to change at any point and frequently do.  Perhaps the only constant is "change" itself, right?

The problem with the traditional approach to development though, is that every time the rules change, the "source code" is immediately stale, and will tend to get more and more out of date over time, because most of the code does not automatically update itself in response to even completely predictable changes in the requirements. 

Instead, the project stakeholders typically have to wait for the python developer to get into their part of the project to update their "source code".  And for the Android team to update the java "source code".  And for the DB team to update their "source code". 

But you can't really have 3 "sources", can you?  That's just not what the word "source" means - right?

Instead, there should always be just 1 (one) source. 

A Single Source of Truth

An SSoT for an entire system/platform is one which authoritatively, in a machine readable, easily queryable format that is not code, defines as much of the final solution as possible.  i.e. A No-Code "Model". 

But importantly, that's not where the story ends.

I'm a developer.  If No-code actually worked today, I'd be out of a job.  Luckily for me though - I think we're probably still at least 5-10+ years away from that reality.  In the meantime however, I still want to write code.  I still want my team of developers to be able to write code. 

But I want them to write as little code as possible in order to accomplish their objectives.  I.e. I want Low-code.  Specifically, even 5 years from now, I will want the human team members to write about 20% of the code, and for the remaining 80% to be derived from specification data (SSoT) - in whatever language/tech-stack we are working in at that point.

Redefining "Source Code"

To understand how this really can actually be possible, we need to start unfortunately, by completely redefining the term "Source Code" itself.  Specifically, we need to pull it apart into the two completely separate things it actually is. 

Source Code = Derivative Code + Hand Code

Once we've done this - it allows us to consider a slight variation from the traditional development stack:

"Traditional" Development Stack

• Framework (node, angular, react, .net, django, etc)
• Static Libraries (shared code, npm, internal tools, etc)
• "Source Code" (mostly written by hand)

With a Single Source of Truth or SSoT as a machine readable specification document, we can add a whole extra layer before the human developers get involved, which can usually encode the vast majority of the business rules/logic for a given system. So essentially, by always starting with language specific, mostly derived SDKs, we can have this stack.

Development based on a Single Source of Truth

• Framework (node, angular, react, .net, django, etc)
• Static Libraries (shared code, npm, internal tools, etc)
• "Source Code" =
• Derivative Code     ~80%    (60-90%?)
  SDKs - mostly derived from the Single Source of Truth, in many cases able to encode the vast majority of the business rules/logic for the underlying system, and having little or no “hand code”.
• Hand Code             ~20%
  i.e. the actual Source Code

The result is a completely different development environment where right from the start, human developers always get to focus on the creative, interesting bits of the project - the last 20%, rather than the other 80% which is usually rote, derivative, patternistic, completely predictable code - i.e. the platform, plumbing, scaffolding, etc. - all the "connective tissue" - regardless of language, environment or technical context.

With this model, the bottom 70-90% of the code that is typically written and maintained "by hand" in a traditional environment is instead derived - so when changes occur (as they reliably always do) as much as 8 out of every 10 lines of code can automatically update itself.  It can simply "following along".  And only the last 15-20% of the code written by hand, may still have to be updated by “real” developers. 

This results in a dramatically more dynamic, flexible, responsive code base, top-to-bottom on which to build; resilient to even substantial changes in direction, or even the more extreme pivots that projects so frequently have to address.  And it's all possible because we're talking about working with as much as 70-90% less "tech-debt" - on an ongoing basis, even years into a large scale project's life-cycle.

No-Code vs. Low-code

At the end of the day, I largely agree with Linus Lee about No-Code specifically.  For the foreseeable future, it will continue to be limited in its ability to fully address the needs of large, long lived, enterprise level systems.  So I'm pretty sure that we'll continue to need "real" developers for at least the next decade.

But in my Open Response to Linus Lee, I argue that No-Code tools are actually already really well suited to providing highly detailed, very scalable, machine readable specification data - which can then be leveraged as the source input for Low-code tools, to supply the vast majority of production ready source code for a given system.  These Tools make the Single Source of Truth...

• Language Agnostic.
• Platform Agnostic.  
• Context Agnostic.  
• Future Proof.

In this way - even when a new, never before seen language "Wombatz" comes out tomorrow (or next year), a single tool will allow us to immediately, seamlessly integrate that language into any of our projects in development for which we have a well defined Single Source of Truth. 

With an SSoT in hand, the newfangled Wombatz code will literally "catch up" to the rest of the languages already in the project - on day 1 - and this can all happen before you've even hired the new human Wombatz developer.

So while I would agree that No-Code tools are still definitely not yet viable on their own as a complete/final solution, they can definitely be used already today to very quickly/flexibly/predictable define the rules for even very complex and sophisticated systems - in a machine readable format - json, xml, swagger, dbml, uml, pfds, etc.  Those rules can then be used to generate production ready code, which simply "follows along" as the rules change over time. 

That process looks like this, even years into a large scale project:

1. Changes are requested by end users (business users)
   
   
2. The No-Code Model is updated to match the changes requested
   
   
3. All of the SDK's derived from the No-Code model, across the entire project stack are regenerated - including APIs, UI, Back-End, Front-End, Databases, Documentation, Unit Tests, Python, Swift, Java, TypeScript, Sql, etc - which will always all tend to match each other - as a set ... because they are all derived from a common description - an SSoT, and they are are not each treated as separate silos of "Source Code".
   
   
4. So by the time the human developers get into the source code (in virtually any technical context), 80% or more of the work is potentially already done, and they can immediately begin to focus on the important/creative/non-intuitive bits - like what the UX should be for the new feature, service, behavior, rule, etc.

Judging "Right" from "Wrong"

 There is no “Right Answer”

In a Traditional Development Model – there is no single, authoritative description of what’s “right”.  If there’s a specification at the beginning of the process, that is authoritative to start out with, but the moment the developers start writing code, the Spec becomes secondary.  At the end of the day, if there is documentation, that hopefully says how the system actually works – but it’s not authoritative, stale and out of date, and frequently just wrong.

In a Traditional Development Model, the same notions/ideas are typically described again and again and again.  Even if multiple languages/platforms are not supported, even a small project might easily have 3 or 4 “copies” of each concept.

1. The Specification
2. The Code
3. The Tests
4. The Documentation

Then, if a change is needed, the process repeats itself.  First, a “Change Request” is created, then the code and unit tests are updated, and then, if there is time, the documentation might get updated as well.

Replication in “the Source Code”

Also, within “the code”, the same ideas are repeated over and over:

1. Interfaces
2. Data Classes
3. APIs
4. Persistence (DB/SQL/NoSql/Etc)
5. Testing
6. Helper Functions
7. etc.

This is before you even get to systems which support/include multiple languages:

1. Java/CSharp
2. SQL
3. JavaScript/TypeScript
4. Json
5. Python
6. etc.

At the end of the day, it’s not uncommon for even small projects to include a description of what a “Customer” or “Widget” is, 10 or more times throughout the code.

Lots of different “Right Answers”

So in a traditional development model – there are typically 3 or 4 ways of doing each thing.  The “database” does it one way, the API slightly differently, the front end differently still.  In this model, there is no “right way” – just different ways.

Introducing a Single Source of Truth

With a single source of truth, (i.e. One, Single, Authoritative, Machine Readable, Description of the problem) things work very differently.  Now, it’s easy to say if any code/documentation/test/api/etc is right or wrong.  Simply compare it to the SSoT.  If it matches, it’s right, if it doesn’t match it’s wrong – and should updated to match.

This is a really important benefit.  It brings a clarity that is simply unmatchable in a “traditional” model.

Spec/Code/Docs – All for 1 and 1 for All

With an SSoT, the Specification is really a report, about a system that already exists.  In other words, writing the specification involves first turning the SSoT into an English description of the technology at hand.

Being able to turn the SSoT into English is proof that the SSoT is sufficiently complete/sophisticated in it’s structure to accurately describe the technology.  If we can turn it into English, we should be able to use different tools to turn it into any language on the planet.

And since both the English Words, and the Code, and the System “Documentation” at the end of the day are all derived from the same, Single Source of Truth, they will all match each other – Because They are Not Source Code.   Instead, to start with, they are all derivative code.  Each derived from the same source.

Now – when the SSoT changes, everything in the repository all changes, as set.  The Specifications, the Code, The Tests, the Documentation, The APIs – All of “the plumbing”.  It all gets updated, together.

Most of what you think of as Source Code is actually completely derivative.

What is A Single Source of Truth

 Overview

Development based on a Single Source of Truth is like creating Cross Platform Interfaces for your Technology.

And just like a Java or CSharp interface, a Single Source of Truth allows you to make decisions once, and then act on those decisions consistently across multiple platforms and environments.

In a traditional development model, the same notions/ideas/concepts are defined again and again, will little to no concern for duplication.

Development based on a Single Source of Truth

To effectively use SSoT.me to develop software, it is important to have a clear understand of what a single source of truth is.

A good single source of truth is a Description of Technology which is a:

1. Single
2. Authoritative
3. Machine Readable
4. Platform Agnostic
5. Queryable
6. Description of What is needed

Single

The most important aspect of a Single source of truth is that there is only one of them.  The most common mistake made in a “Traditional Development Model” is that the same notions are described again, and again, and again – and in each place we call that “Source Code”.

Authoritative

Many projects actually have development assets which would make good Single Sources of Truth, but they lack Authority.  In other words – after finding a good Single description of what is needed, the next KEY is designating that description authoritatively as “the” description.

Machine Readable

Another key aspect of developing an SSoT is that it must be machine readable.  Creating a single, one page picture of the technology is a fanstastic start.  But if that picture is embedded in a PNG that’s not as helpful as if it is in a simple JSon or Xml Description of a flow chart..

Platform Agnostic

SSoT’s which are easily read by Mobile, Desktop, Windows, Web, iOS, Android, Linux, etc are better than Single Sources of Truth which are targeted at a particular environment, language or technology.  Good examples of platform agnostic SSoT’s are:

• Json
• Xml
• Csv
• Xlsx
• DBs (Sql, Postgress, MySql, NoSql, etc)
• Google Docs/Sheets
• etc

 

Description of What is needed

A key aspect of a good Single Source of Truth is that it contain as many of “the decisions” that have been made as possible.  In other words, the SSoT is the perfect place for all of the tribal knowledge.  In other words, once you’ve created the SSoT, there should be no tribal knowledge.

Because anything that would ordinarily be treated as “tribal knowledge” should be written down!