System News
'Conscientious Software': A New Approach to Development
Ron Goldman Shares His Insights with Janice J. Heiss
April 24, 2006,
Volume 98, Issue 4

It won't be easy to convince people that they need to accept that software will always have errors or that performance is of secondary importance.

-- Ron Goldman
 

Ron Goldman is a senior staff engineer at Sun Microsystems Laboratories currently engaged in research with colleague Richard Gabriel on what the pair term "conscientious software," large systems that are robust, stable and capable of managing themselves. This work stems from Goldman's belief that interoperable, networked computing is headed in a direction that well reduce the reliance on and importance of standalone applications. Janice J. Heiss spoke with Goldman recently and reported part one of her interview for the Sun Developer Network.

Goldman summed up his view on the nature of current software by citing a paradox, namely that, "...to be useful, software must depend on other software; but to be reliable, it must be independent -- able to maintain its integrity in a changing environment." The code now available for software development, Goldman continued, is better suited to creating small scale solutions; larger scale solutions, requiring more robust code, typically wind up ad "brittle" and failure prone.

Developed on a manufacturing model that results in products that are shipped and expected to run flawlessly, contemporary software solutions work fine, generally, Goldman asserted, until they are required to function interoperably, which is when their bugs emerge. What is called for, he contended, is software capable of monitoring its own environment and behavior and continually performing self-testing that will "...catch errors and automatically recover from them, automatically configure itself during installation, participate in its own development and customization, pay attention to how humans use it and become easier to use over time," capable even of protecting itself from damage that results from the installation of patches and updates.

This thinking is what led Goldman and Gabriel to the expression "conscientious software," which takes responsibility for itself. Some of this capability is already available in such things as plug-in architectures and web-service-based applications that accept post-installation, he observed. Molding customer opinion to accept this point of view, Goldman claimed, will be a big job: "It won't be easy to convince people that they need to accept that software will always have errors or that performance is of secondary importance."

It is pointless to expect code to be without errors, no matter how extensive the testing, Goldman asserted. Bugs in the implementation and inputs from the environment can never be entirely anticipated, he pointed out, especially when one piece of code is changed and then interacts with other code in unexpected ways.

As a consequence, Goldman recommended using runtime resources for error detection and recovery, citing John McCarthy's design of the LISP language when he used an algorithm for the purposes of symbolic differentiation, accepting the limitation that "...all programs have bugs [which call for a] system that can repair and clean up unused memory and, in a sense, that can recycle it and make it available."

Goldman said he sees no point in expecting programmers to perform such tasks as freeing up memory as it becomes available as well as the computer itself can. "Our software should be an active participant in maintaining its integrity," he argued, adding that new mechanisms are called for if this change is to be realized. And the notion of performance needs to be expanded to include such considerations "...as usability, robustness, security, and all the other factors that define the behavior of our programs."

Much can be learned, Goldman suggested, from biological models. "One idea that seems promising is to separate the software that does the work from the software that keeps the system alive. In computing, perhaps 5% of our code deals with exception handling and error correction, which seems like a lot, while 95% tries to get the basic job done. Biology appears to reverse this, with 5% doing the basic metabolism and 95% functioning to make sure that the 5% can do its job."

Biology has taught him about allopoietic and autopoietic functions, Goldman explained. Allopoietic systems make things outside themselves; autopoietic systems make themselves. He likened banking systems to allopoietic systems, taking inputs and performing a required functionality. Using contemporary code to make such solutions more robust by adding exception handlers and error detection code, he continued, results in solutions that are difficult to understand and to maintain.

Instead, Goldman urged the creation of autopoietic systems that both generate and control their own development. "We want to take the allopoietic components and embed them in a larger autopoietic space with components that are working to maintain the integrity of the system." Such a program calls for a language with which developers might construct complex feedback networks, he indicated, which is rather beyond the capabilities of either C++ or the JavaTM programming language in his view.

Heiss brought up the notion of software able to "see" into its environment and make adjustments as necessary. Goldman responded, saying, "We believe that it is important to have visibility into the system in order to assess its health and to make decisions about adjusting it. Visibility consists of continually updated descriptions, for example, of what's inside a system's software components, how a system is currently configured, the overall state of the system, what it's working on, which users use what software in which ways, and so on."

He continued his explanation with a comment about "stigmergy," another expression borrowed from biology, which he defined as the ability of the individual components of a system to communicate with each other indirectly by modifying their local environment." He likened this to the ability of JavaSpacesTM technology to write data into a space that other processes can then read, do computation based on what they've read and then possibly write new data into the space.

On a somewhat larger scale, he concluded by likening what he has in mind for software to the parenting process in which adults gradually alter their roles as decision makers for every instance of a child's life while simultaneously imbuing the child with the ability, ultimately, to make decisions for itself. "With luck, persistence, or good upbringing, the child may become conscientious. We hope the same for our software," he said.

Read part one of this interview in its entirety at A Conversation with Sun Microsystems Laboratories\' Ron Goldman. In the second part of her interview, Heiss will write about Goldman's insights into open source, about which she said Goldman and Gabriel have written in their book, "Innovation Happens Elsewhere: Open Source as Business Strategy." "

Read More ... [...read more...]

Keywords:

 

Other articles in the Features section of Volume 98, Issue 4:

See all archived articles in the Features section.

Popular Articles in
Vol 198, Issue 5
Popular IT Articles





Popular Articles in
Vol 198, Issue 5
Popular IT Articles


News and Solutions for Users of Solaris, Java and Oracle's Sun hardware products
Just the news you need, none of what you don't – 42,000+ Members – 24,000+ Articles Published since 1998