Good question. It is related to the genetic algorithm concept, automated bug detection, and continuous integration.
Early Genetically Inspired Algorithms
Some of the Cambridge LISP code in the 1990s worked deliberately toward self-improvement, which is not the same as self-repair, but the two are conceptual siblings.
Some of those early LISP algorithms were genetically inspired but not pure simulations of DNA mutation with natural selection through sexual reproduction. A few of these evolution-like algorithms evaluated their own effectiveness based on a fixed effectiveness model. The effectiveness model would accept reported objective metrics at run time and analyze them. When the analysis returned an assessment of effectiveness below a minimum threshold, the LISP code would perform this procedure.
- Copy itself (which is easy in LISP)
- Mutate the algorithm in the copy according to some meta-rules
- Run the mutation in parallel as a production simulation for a while
- Check of the effectiveness of mutation out performed its own
If the mutation was gauged as more effective, it would perform four more selfless steps.
- Make a record of itself
- Attach its own performance for later meta-rule use
- Load the mutation it created in its own place
- Perform apoptosis
Unlike biological apoptosis, apoptosis in these algorithms simply pass computational resources and run time control to the mutation that was loaded.
This procedure was and probably still is easier in LISP than in other languages, although lovers of other languages would argue endlessly that point.
Extensions of Continuous Integration
This is also the closed loop continuous improvement strategy intended when bug reporting is integrated with continuous integration development platforms and tools. We see extensions of continuous integration in the feeding of bug lists from automated detection, especially for crashes, in many applications, frameworks, libraries, drivers, and operating system today. Many of the elements of closed loop self-repair are already in general practice among the most progressive development teams.
The bug fixes themselves are not yet automated in the way researchers were attempting in the LISP code above. Developers and team leaders are following a process similar to this.
- Developer or team lead associates (assigns) bug to developer
- Developer attempts to replicate the bug with the corresponding version of the code
- If replicated, the root cause is found
- A design for a fix occurs at some level
- The fix is implemented
If continuous integration and proper configuration management is in place, at the point when a commit of the change to the team repository occurs, it is applied to the correct branches and the test suite of unit, integration, and functional tests is run to detect any breakage that the fix may have caused inadvertently.
Several Pieces of Full Automation are Already in Use
As one can see, many of the pieces are in place for automatic algorithm, configuration, and deployment package self-repair. There are even projects underway in several corporations to automatically create functional tests by recording user behavior and user answers to questions like, "Was this helpful?"
What is Missing
What needs further development to more completely see full life cycle self-improving and self-repairing software?
- Automatic bug replication
- Automatic unit test creation
- Automatic repair design
- Automatic creation of code from design
I suggest that the next steps to be done are these.
- Assess work already done on the four missing automations above
- Review the LISP procedure that was perhaps shelved in the 1990s, or perhaps not, since we cannot see (and should not see) what was classified or made company confidential)
- Consider how the machine learning building blocks that have emerged within the last two decades may help
- Find stakeholders to provide project resources
- Get working
A Note on Demand, Ethics, and Technological Displacement
Truth be told, the quality of software was a problem in the 1980s, 1990s, 2000s, and 2010s. Just today, I found over a dozen bugs in software that is considered a stable release, when performing some of the most basic functions the software was designed to do.
Given bug list sizes, just as accidents make the question of whether humans should be driving cars questionable, whether humans should maintain software quality is questionable.
Humanity has survived replacement in a number of things already.
- Arithmetic with a pencil and eraser is gone
- Professional farming with garage tools is gone
- Creating advertising mechanicals with Exacto knives is gone
- Sorting mail by hand is gone
- Communicating by horse-back courier is gone
Few software engineers are happy just fixing bugs. They seem to be happiest creating new software filled with bugs that someone else is supposed to fix. Why not let that someone else be artificial?