Don’t write code… build Vendors.

This isn’t open source, and it isn’t closed source. It’s no source.

Once upon a time, we wrote programs in assembly.

Then, when programs became too complex, we abstracted away the details of the machine and moved from assembly to higher-level languages. Here, we began to capture a little of our knowledge in libraries.

We wrote a little less, and re-used a little more.

Today, we routinely re-use code to great effect. Yet we still need to write the code that integrates the modules, that threads together the knowledge, that allows us to actually re-use the code.

Now, we have the ability to go one step further, to capture all our knowledge in Vendors — including the knowledge of integration — so that we no longer have to write a single line of code.

But somewhere, “somebody does write the code, correct?”. Not so… a developer in this new software development system no longer writes any code. In fact, nobody in this system writes code — design directly gives way to binary CPU instructions. (No compilers, HLLs, generators, AI, magical elves or <insert assumption here> of any kind are needed.)

But, the role a developer plays in this new system is not all that different!

You still capture knowledge (like you did in libraries). You still help build software.

The difference? You don’t write code. You build Vendors.

And now, you get paid every single time another developer uses your knowledge — every single time your Vendor is contracted.

For now, it may help to think of it like this; imagine you created a kind of library module (without hand-writing code — we’ll get to that), and any time another developer used that module in their application (or larger module), you were paid. Every time.

The best way to explain this fanciful notion — building software without writing any code — is by answering one simple question; what can a library do that a Vendor can’t?

(1) Libraries are a form of knowledge re-use.

“The value of a library is the reuse of the behaviour.”

The value of a Vendor is the reuse of the design of the behaviour.

Check. So far so good.

(2) Libraries are a vital means of abstraction.

“When a program invokes a library, it gains the behaviour implemented inside that library without having to implement that behaviour itself.”

When a Vendor contracts another Vendor, it gains the expertise — the design of the behaviour — inside that Vendor without having to implement that expertise itself.

Check.

So far, equating a Vendor with a library function may sound almost analogous, and deceptively so.

But if we take a look at the third criteria for libraries, a glaring difference arises…

(3) A library is designed to be modular.

“Libraries encourage sharing of code in a modular fashion,” where the library module is a separate software component that can be executed in isolation, and therefore re-used by other applications.

In short, the library module — the knowledge — is modular and its code is also modular, because they are one and the same. However, this ‘code modularity’ forces developers to write additional ‘glue code’ around them in order to integrate different modules.

Vendors — the knowledge — are modular but their code is not. You cannot run the code ‘returned’ by a Vendor in isolation.

But this is not a flaw of this system, it is arguably its greatest feature.

The code ‘returned’ by a Vendor is tailored to integrate perfectly into the larger application without any need for ‘glue code.’ This is because Vendors cooperate so intricately at design-time of the overall application (in order to determine their code’s run-time context) that ‘integration’ becomes as simple as joining bytes together and then passing them up to the client — in short, concatenation. (Indeed, the code returned by a single Vendor may even be smeared across the final executable.)

Because Vendors can apply their expertise to any project, we still retain the advantages offered by modularity that warranted the creation of libraries in the first place. But now we remove the added burden of integration, and with it the last vestiges of written code.

At the end of the day, you can write a library module and leave other poor souls to fend for themselves when they try and integrate it. Or you can implement that same knowledge into your very own Vendor which will naturally integrate code on your behalf.

Oh, and you get paid every time.

Don’t write code.

Build Vendors.