How does this make any sense?
Josh Koch
1

Have you had a chance to check out https://codevalley.com? I’ll provide a brief overview here of how it works.

In creating a block of code (whether it be a function, or patch, or pull-request etc.), you will make many decisions, which result in the code you write, but which do not actually have a presence in that code.

Ultimately, we could summarise the current role of most developers as one of predicating and delegating. But the predicate knowledge stays locked inside their mind, only to be ‘triggered’ again at some point down the line when the time comes to write similar code. At present, there are no tools that allow a developer to capture that knowledge and allow it to be reused. Tools only exist for the requirements delegation, in the form of HLLs and compilers etc.

This tool allows you to do both; to create a program that negotiates its own interface (at your direction), makes the same decisions you would, and ultimately delegates the responsibility of code production to other programs like itself, effectively decentralising a small portion of the overall design. This Vendor program that you create is automated to handle all aspects of the design, which makes the Vendor itself reusable (but not the code it returns, which is actually a very good thing).

At their run-time, hundreds upon thousands of Vendors will come together to design an application. Each Vendor program will contract other Vendors programs that contract other Vendor programs and so on. Each iteration of contracts results in a collaborative translation of (n+1)-level requirements into (n) level requirements, deferring the production of code, and decentralising the design a little further.

As long as a Vendor has not yet returned its fragment of code, it will preserve connections with its client and suppliers. Thus, by the time the deferral of code production has reached Vendors who are at the end of the abstraction line (the ‘byte Vendors’), a large and very elaborate decentralised ‘design framework’ has been established between all Vendors who were contracted as part of the build.

Once the byte Vendors place binary CPU instructions and return these tiny fragments to their clients, they sever the connection with their clients (and the clients reciprocally sever their connections with their suppliers, having now received fragments of code). The returning of bytes and severing of connections continues, as the fragments of bytes grow and climb back through the layers of abstraction until the final string of binary CPU instructions (the program itself) arrives at the topmost client. The framework itself is dismantled much the same way it was created; in an incremental and decentralised manner.

The etymology of the term ‘framework’ in software is clear; in construction, a framework is the skeletal arrangement of beams that permanently support the overall structure. Likewise, in software, an application is ‘supported’ (and supplemented) by its host framework. Such support requires permanence in order to ensure the integrity of the structure.

However, the ‘framework’ established during the process of decentralised design is ephemeral; it is an integral part of the construction (i.e. design-time) process, but has no place in the run-time of the application. For this reason, it seems more fitting to refer to this decentralised framework as formwork, another term used in construction that refers to the temporary mould into which concrete is poured. Once the concrete has cured, the formwork is removed, and the concrete is put to use. Likewise, in this process, once the application has been constructed (i.e. all bytes have been returned), the connections are severed and the application is put to use.

A Vendor will return a fragment of code, but a single fragment only. There is no run-time switch to decide which part of the fragment is executed based upon the type. Rather, it is more accurate to say there is a design-time switch inside the Vendor that will alter how it subsequently designs its code (i.e. which suppliers it will contract). (Of course, this switch will actually occur at the run-time of the Vendor program itself, which is the design-time of the overall program being constructed.) All Vendors decide live, during the build of the overall program the details of their interfaces, and adjust their subsequent designs accordingly. The formwork in its entirety is a result of the collective decision-making of a decentralised network of programs responding to a particular set of program requirements. Each Vendor (eventually) returns a heavily customised fragment of code, which slots into what forms the client’s own fragment (where memory is contiguous), like a Russian nesting doll being assimilated into its Matryoshka parent. As a result, we end up with an application with only one dependency; the platform itself.

Software development is utilised to completely automate tasks.

Yet complete automation has not yet been fully utilised to develop software.

It might appear contradictory at first, but to truly automate the process of software development, developers themselves become more crucial than ever, and are actually integral to the success of this process.

Developers (manually) build the Vendors.

Vendors (automatically) design and construct software.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.