Listen to this articleCode Valley technology has the potential to industrialize the software industry. This technology is requiring a shift from the ‘code-domain’ to a ‘design-domain,’ where a peer-to-peer network of specialist vendors co-operate to make design-contributions. Fueled by bitcoin, this network forms a global supply-chain which is capable of reliably building immensely complex software programs. Below is our interview with Julie from Code Valley:
Q: Julie, how would you describe Code Valley in your own words?
A: Despite its staggering accomplishments of the last 50 years, the software ‘industry’ is still very much in a state of pre-industrialisation, which begs the question; “What could have been?” In all other industries, projects are completed by harnessing a supply-chain to design and construct the final product. To draw an analogy from the Civil industry for example, the construction of a bridge begins with the Principal contractor, who contracts high-level bridge-specific contractors, who then contract top-level contractors to build certain components (e.g. foundations, piles, abutments etc.). But these contractors actually have sub-contractors of their own (to dig the foundations, insert steel reinforcement, pour concrete etc.). And these sub-contractors have sub-contractors of their own, and so on. We could actually trace this process right ‘down’ to the very quarry from which the aggregate for the concrete was sourced.
Over in the software ‘industry,’ projects are completed in a ‘flat,’ more generalist fashion, without using the power of supply-chains or specialisation. And not for lack of trying. The idea of ‘software componentisation’ has actually been around for nearly as long as software itself. In 1968, software pioneer Douglas McIlroy envisioned a software components industry which could lead to the industrialisation of software. However, such a components industry never came to fruition due to two fundamental problems; an inability to specialise, and a bizarre backward view of component integration. Code Valley has solved both of these problems and opened a path for the final industrialisation of software.
For the last 50 years, the software industry assigns the responsibility of component integration to the ‘client’ (the selector of the component). In all other industries, this responsibility is the other way around; the supplier builds their part (the component) into the client’s project. In the Civil analogy, the contractor building the bridge abutment is granted access to the bridge construction-site and builds the abutment ‘into’ what becomes the bridge. This gives the contractor the ability to tailor the abutment for the project, delivering an efficient and seamless portion of the bridge. If the responsibility for integration as it is in the software industry were applied to this analogy, the Principal would select a (largely) fixed “abutment” from a software library (the abutment contractor is long gone) and this (non-abutment expert) Principal would be expected to “make it fit” using lots of “filler” and bits of “concrete” (what we call glue code), resulting in a potentially dangerous, quite inefficient and almost certainly an ugly bridge.
( Click to enlarge )
Recommended: Intersec Raises 10 Million To Fuel Innovation Of Its Smart Data Software Solutions
It is this backwards responsibility, coupled with an intangible end-product that has made it virtually impossible (up until this point) for developers to make a living as a specialist. All other industries enjoy physical goods – concrete and steel cannot be ‘replicated’. When the Principal needs the same ‘component’ (a bridge abutment, for example), he cannot go and instantly replicate the existing abutment, he must return to the relevant sub-contractor. But in today’s software industry, code can be instantly replicated and used again and again, destroying any ability for a developer to make a living as a specialist.
How does Code Valley solve these problems? By doing away with source code itself, the very backbone of today’s software industry. Instead of a code-contribution, developers now make a design-contribution to a project.
But what does a design-contribution actually mean? Taking the abutment contractor as an example, we can observe a design-contribution in action. The abutment contractor was given a contract which included;
1. some high level abutment requirements,
2. access to a portion of the bridge construction-site (where he is to design and build said abutment) and,
3. payment.
Surprisingly, the abutment contractor never lifts a shovel (never touches code). Cleverly, using his own knowledge of abutment design, he merely grants a number of contracts to his tried and trusted sub-contractors who integrate smaller features such as excavating, inserting steel reinforcement, pouring concrete etc. at a location in the abutment construction-site as instructed. Each contract includes;
1. some high level feature requirements,
2. access to a portion of the abutment construction-site (where the contractor is to design and build said feature) and,
3. payment.
The abutment contractor has made a design-contribution, yet borne out of this is a physical and completely customised new abutment. Sound familiar? It should, because the Principal contractor is also making a design-contribution; one that is delivering an entire bridge! Also note the abutment contractor’s sub-contractors do not (and need not) know they are actually constructing an abutment. And from the perspective of the Principal contractor, the abutment contractor is seen to have “designed and constructed” an efficient, seamless abutment that requires no extra filler/concrete on the Principal’s part (no glue code).
To arrive at a software program, one merely selects the features they want the program to have and contracts experts at designing these features from the top of the supply-chain. Each contracted supplier knows how to co-operate with their peers to build their feature into a project and ensure a binary is returned satisfying these features. There is no glue-code for the developer to write. (In fact, there is no code that any developer anywhere in the supply-chain has to write.)
To carry out this ‘feature selection’ and build a software program using the Code Valley system, a developer will use a special vendor – a ‘Principal’ – which is a domain-specific program that captures the high-level requirements of the program to be constructed. After capturing these requirements, the Principal program automatically contracts vendors in the top levels of the supply-chain, who will then contract other vendors a little lower in the supply-chain, who contract other vendors lower still and so on. This process continues right down to the hardware where foundation vendors place bytes into their tiny portions of the construction site before passing the filled construction-sites back up to their immediate clients. The clients join the filled construction-sites and pass them up to their own immediate clients and so on, until the final pieces of the filled construction-site are joined by the Principal to reveal the final binary executable.
Recommended: ArCycle Software – Tailored Enterprise Backup And Disaster Recovery Solutions
Q: You have created a technology that allows a developer to contribute to a software project and earn bitcoin for each contribution; could you explain it?
A: Software design is perfectly suited for the application of design-contributions. And because software is an intangible end-product, the entire design process can be leveraged to actually construct the software. (Let’s see the Civil industry do that!)
To deliver a design-contribution in the Code Valley system, a developer must first create a Vendor, which is a program that can be thought of as an ‘automated assistant’ of the developer. A design-contribution is made by capturing requirements, making decisions, and contracting lower-level Vendors. These are all discrete steps that can be easily automated. Doing so would allow a developer to make many thousands of design-contributions to many thousands of projects every minute, and be paid for every single contribution. By automating the expertise of developers using these vendor-programs, this system becomes a completely automated supply-chain inside the software development process.
And to build one of these vendor-programs, a developer uses the supply-chain itself. Using a Vendor-Principal, a developer expresses their Vendor requirements (who it should contract, and based on what given requirements, and how it should negotiate in committees), which are translated by the Principal to direct contracts to the supply-chain. In moments, that Vendor will be ready for testing by its developer-owner before they open for business in the Valley, the global repository advertising all Vendors currently available for contracting.
When a Vendor is paid for its design-contribution, it in turn pays its suppliers, pocketing a nice margin in between for its developer. This unique use of a supply-chain to construct software results in millions of contracts per project. As these vendors can be located anywhere in the world, the payment methods can become very complex, inefficient and fraught with AML, CTF and compliance issues. Bitcoin enables this technology to go global.
Q: Could you tell us more about key features?
A: Code Valley brings high levels of automation and intellectual property (IP) protection to the developer, qualities which favour the professional rather than the low-wage earners. As this system uses design-contributions, which scale perfectly (unlike components, modules, routines, objects, beans etc), the entire spectrum of design is open to specialisation (and automation), which, together with the natural IP protection afforded by the design-domain, protects a developer’s prospects for repeat business.
To become a part of the supply-chain, a developer first registers an account with Code Valley, where they choose their Valley handle (the identifier by which they will be known in the Valley). Once the developer has an account, they can then log in and begin building Vendors. Upon login, a developer will have access to five portals; Valley, Portfolio, Finance, Expression, Testing.
1. Valley – The Valley portal can be used to browse a global list of all Vendors currently open for business. The Valley is a highly standardised information repository, which makes both searching and adding to the database a seamless exercise. Each new Vendor that is published to the Valley will reside under a number of tiered classifications, making it very easy for prospective clients to find. As well as containing a list of Vendors available for contracting, the Valley also lists metrics associated with each Vendor; their total publishing time, their total number of contracts, and their code footprint (a smaller footprint relative to a Vendor’s competitors indicates a superior Vendor).
2. Portfolio – Each Vendor that a developer builds will be listed in their portfolio, along with the current metrics displayed alongside that Vendor in the Valley. It is in their portfolio that the developer will modify the current price of their Vendor at will.
3. Finance – Due to the sheer quantity of contracts that will flit around the network on a daily basis, it is prudent to aggregate payments (and in future, use micro-payment channels). For this reason, all payments made during a particular settlement period are aggregated and listed in the finance portal. The developer has the length of the settlement period to settle accounts. This Finance portal contains an aggregated list of accounts payable (users in the network who are owed payment because the developer’s Vendor has contracted one of their Vendors), and accounts receivable (users who owe the developer payment because they have contracted one or more of the developer’s Vendors).
4. Expression – The Expression portal gives the developer access to their very own Vendor-Principal, the ‘software factory’ that a developer uses to engage the supply-chain to build their own Vendor. Once the developer is satisfied with their Vendor’s expression, they submit it to Code Valley who will build and host their Vendor for them (until the completion of the McIlroy phase of release, at which point developers host their own Vendors on their own hardware). Once built, the Vendor will appear in the developer’s Portfolio, where it is now locally available for contracting (to build acceptance tests). Once these test/s have verified that the Vendor’s design-contribution is sound, the developer can then officially publish their Vendor to the Valley, instantly making it available for contracting.
5. Testing – The Testing portal is a Principal that allows a developer to contract their own Vendors to build tests that use their Vendor’s design-contribution. Any acceptance tests that demonstrate a viable design-contribution also confirm that (at that point in time) every single supplier ‘beneath’ the developer’s Vendor (all the way to foundation) also provides viable design-contributions.
Recommended: stable|kernel: Great Brands Deserve Great Mobile Software
Q: How would you convince the reader to start using Code Valley?
A: This technology does not mean the replacement of craftsmen with assembly lines. The supply-chain is not replacing developers, the supply-chain IS developers. Whilst the role of a developer in this new software industry will take a different form, there is still just as much (if not more) earning potential. Firstly, a vendor-program allows a developer to automate their expertise, and sit back whilst that Vendor builds design-contribution after design-contribution into project after project, earning a continuous stream of coin. This is vastly different from current best practice which sees a developer write (by hand) a substantial portion of the program that they have been contracted to deliver. Developers with a broad array of hard-earned expertise can cast that expertise into many Vendors and put these to work in the supply-chain. By recording the metrics of each Vendor’s performance against their developer-owner’s handle in the Valley, the superior Vendors are quickly illuminated, and will naturally be rewarded with more contracts from clients. The Valley becomes a direct mechanism through which the quality, value and merit of a developer are visible for all to see.
At its core, this software development system is a highly collaborative yet fiercely competitive community. In the early days of the supply-chain, the relationships between clients and suppliers in this community will be tenuous, but growing stronger and more reliable with each contract. Since clients are the very livelihood of a developer’s Vendor, it is important to maintain their trust and satisfaction. Similarly, it is in the developer’s best interest to establish a list of trusted suppliers for their Vendor as it will inherit their reputations (good or bad). (If they look good, the Vendor looks good.) For this reason, it is important to begin cultivating these client and supplier relationships as soon as possible.
At present, the supply-chain contains few Vendors and is full of voids. But a void represents opportunity – it represents demand. Those who join the network in the early stages will be met with limitless opportunity and almost zero competition. The barrier to entry is never lower than it is now. But that lowered barrier comes with a price. The network is new – it is volatile. Market-verticals are still being assembled. It will take some time before the network becomes profitable for its participants, before it can compete with current methods. But this technology has a fast path for improvement, and the first to establish themselves in this supply-chain – this marketplace for expertise – are better positioned to reap the long-term rewards.
Q: What can we expect from Code Valley in next six months?
A: Code Valley’s roadmap for release consists of three milestone-driven phases; Whitney, Ford and McIlroy.
Whitney is designed to introduce the technology to the community. In this stage, there are many voids to be defined and populated, and competition is virtually non-existent. For this reason, this phase of release will operate in private beta.
Code Valley is currently seeking expert developers from any and all layers of abstraction to give this marketplace the widest and most productive coverage of strategic verticals during this early stage of growth.
When building a Vendor, the focus during Whitney is not on negotiations, or sophisticated automation of Vendor operations. The focus is simply on automating the design of algorithms, which amounts to ‘casting’ the knowledge of existing expertise of developers into Vendors. The intellectual and financial barriers to entry are lowest in Whitney. The community is new, developers are learning the ropes, and the driving force of innovation – competition – is not yet in full effect.
Although the barriers to entry are lowest in Whitney, this should go hand in hand with an expectation of intermittent revenue for vendors in these early stages of the network. Vendors will not be continuously profitable until they belong to a functioning market-vertical for which there is demand amongst end-users. However, Vendors can expect sporadic contracts almost as soon as they are published in the Valley, as a vertical is assembled from the bottom up. Developers will build their Vendor, and create an acceptance test program by contracting their own Vendor, which indirectly contracts suppliers ‘below’ their Vendor, all the way to foundation. Thus, a developer’s Vendor can receive legitimate contracts (and associated payment) before it yet belongs to a completed vertical. As soon as a client exists for the Vendor, the developer will begin receiving payment.
The primary goal of Whitney is to assemble a functioning market-vertical of Vendors, capable of building a particular application for which there is demand. Ideally, this first vertical will be a Bitcoin vertical (i.e. a wallet, node, mining application). As soon as a market-vertical is up and running (albeit, with its constituent vendors all sitting at the origin of the technology progression curve), any modicum of improvement made to its Vendors will result in emergent improvement of the output executable. And that ‘improvement’ is the goal of the next phase of release; Ford.
Ford is the second phase of release in our roadmap, and is designed to introduce the community to the concept of negotiations. This is where the true power of the design-domain becomes apparent. Output executables built during the Ford release will be more efficient, leaner, and contain more features, when compared with their earlier versions built during Whitney. Now that developers have cast their algorithmic expertise into a Vendor, they can start to make that Vendor ‘smarter,’ by including negotiations and more advanced decision-making capabilities.
In Whitney, Vendors are automated to administer algorithmic design-contributions, where Vendor representatives are provisioned to be in contact with all the necessary peers to ‘negotiate’ the outcome of a particular requirement. However, despite being in the same committee, little use is made of this valuable communication outlet. In Ford, there is now the potential to utilise committees for their true intended purpose; to negotiate to optimise Vendor design-contributions. This requires most (if not all) Vendors within the marketplace to progress up the technology progression curve at similar rates. If just one participant of a committee of ‘smart’ Vendors is ‘not-so-smart,’ the ‘smart’ Vendors will have to default to the catch-all negotiation outcome, and their designs will be subsequently affected. (Of course, these ‘not-so-smart’ Vendors will eventually begin to suffer the consequences of their lack of evolution, and lose market-share to other more willing entrants to the network.)
The Whitney release culminates with the construction of an application built by the network. The Ford release will culminate with the construction of that same application, but built using the newly evolved Vendors within the marketplace.
During Whitney and Ford, Code Valley will waive license fees to minimise the financial barrier to entry and support newcomers. However, in Ford, the intellectual barrier to entry will have risen, as first-mover developers who built Vendors during Whitney have familiarised themselves with the technology and are working to improve their vendor designs, putting them ahead of the curve of later entrants.
McIlroy is the third and final phase of release in our roadmap, and the precursor to complete decentralisation of the marketplace. When McIlroy is complete, any developer in the world will be able to rebuild their Vendor and be delivered a feature-complete Vendor executable, to run on their own hardware and be a node in a global peer-to-peer decentralised marketplace for software expertise. The Valley itself will also become decentralised, and be distributed amongst all nodes in the network. It is at this point in the marketplace’s history that it will be truly scalable, capable of sustaining (and thriving on) any rates of adoption.
Finally, since the community itself would have built Vendors for the Vendor vertical that will incorporate the desired features in an output Vendor executable, the community will enjoy payment every time a member of the community rebuilds their Vendor to transition to the decentralised marketplace. Furthermore, since the Vendors that were added to the Vendor vertical have the opportunity to harness the power of negotiations, they will do their part in ensuring the final Vendor executable that each developer receives will be deservedly efficient.
This mass-wide rebuild of Vendors to transition to a truly decentralised marketplace will be the final milestone that completes the decade-long vision for this technology. And it will be the community that makes that vision a reality.
Activate Social Media:
