# Emergent Coding

Emergent Coding is a decentralized software development paradigm employing a type of software component that cannot be copied or reused with the objective of achieving both workable developer specialization, and a practical software components market.

## Description

Emergent Coding is a decentralized software development paradigm employing a new type of software component that cannot be copied or reused. The method ensures developers can safely list their software components for public sale without endangering prospects for repeat business, a feature essential for both workable developer specialization, and realizing Douglas McIlroy's 1968 vision of a software components market.
The change is a reversal of integration responsibility such that instead of fetching a component in a traditional sense, a developer provides a project construction-site to the supplier with that supplier now integrating their component into the project. The reversal switches the view of components from a library-of-routines to a catalogue-of-design-services.
The reversal permits this new component type to properly scale as the construction-site can be readily partitioned to engage sub-contractors allowing components to be fielded as an assemblage of smaller ones which do likewise. Scaling down allows small components to absorb the role of the traditional compiler, removing its centralism from software development while scaling up results in domain-specific components for expressing project requirements.

## History

Douglas McIlroy at a NATO conference in 1968, observed: "The Software Industry is Not Industrialized" and proposed a software components market with component "distribution by communication link” whereby “even very small components might be profitably marketed". McIlroy imagined a "Sears-Roebuck" style catalogue "to have for [his] own were [he] purchasing components." McIlroy's proposal did not address how viable developer specialization might come about if we are to turn our "crofters" into "industrialists". Specifically, while it is easy for a developer to specialize, it is virtually impossible for them to build a viable business as a specialist.
In late 1994, Noel Lovisa proposed reversing the integration responsibility as a means of shielding supplier intellectual property, thereby preserving prospects for repeat business, and establishing a workable basis for developer specialization. Lovisa founded Code Valley Corp Pty Ltd in May 2000 to create and field a practical software components market based on the principal, releasing a white paper in 2016, and conducting trials of a centralized software components market that same year. In June 2018, Lovisa delivered a keynote address at ICSE 2018 in Gothenburg, Sweden which, being the 50th anniversary of the 1968 NATO Software Engineering Conference, was attended by McIlroy and other industry leaders. In September 2023, McIlroy extended an invitation to Lovisa to present Emergent Coding at Dartmouth College, New Hampshire.
In late 2023, Code Valley began trials of a decentralized and fully non-custodial software components market featuring a custom Integrated Development Environment (IDE), over 5000 software components occupying 4 levels of abstraction (Behaviour, Systems, Data, Byte), a Distributed Fault Tracing System (DFT), a peer-to-peer electronic cash payment system, and an interactive catalogue of component prices, data sheets, contract specifications, and reference designs.
The implementation, itself built with emergent coding, is expected to publicly launch in 2025.

## Emergent Coding Software Development

Component Based Software development begins with drafting an expression containing a series of contract statements for engaging the desired component suppliers assisted by the contract specifications published in the component catalogue. As all components in the catalogue have a listed price, the total cost of the project can be reliably determined from the expression before committing to construction. When the expression is deemed in order and the costs acceptable, the project can be built. During the build process, the IDE parses the expression and engages the contractors by forwarding contracts and payments to each. These contractors receive a portion of their requirements via their contract terms directly with the balance determined via collaboration between contractors as authorized by the contract terms. Each component contractor concludes their contract by returning a fragment of code and data that when concatenated, forms the resultant project binary.
Each contractor engaged, verifies payment and allocates a job against the contract, being sure to return the job number to the client so they may forward communication authorizations for the collaborations between contractors as detailed in the expression. These contractors receive a portion of their requirements via their contract terms directly with the balance determined via collaboration with peers as authorized by the contract terms. Once in possession of project requirements, each sub-contracts smaller components as directed by their special knowledge, which do likewise. Each component subcontractor returns a fragment of code and data that when concatenated, form single code and data fragments for receipt to the client concluding the contract.
Leaf contractors in the project contracting tree similarly verify payment and allocate a job against the contract, being sure to return the job number to the client so they may forward communication authorizations for the collaborations between contractors as detailed by their special knowledge. As before, these contractors receive a portion of their requirements via their contract terms directly with the balance determined via collaboration with peers as authorized by the contract terms, however, as a result of gaining sufficient understanding of their design-time context, they render their code and data fragments directly for receipt to the client concluding the contract.