Original Introduction

Greg Bryant

Progress in computing is the result of exploration, and the time taken to communicate hard-won knowledge. In recent years, we've published more, and as a consequence, our ability to repair software, to analyze existing software, and to collaborate, has greatly improved.

But we have not begun to study sequences of good development, the stepwise unfolding of work by engineers who've done the same application in the same environment for the Nth time. Engineers who are completely comfortable solving problems for one platform can avoid bad development paths, and convey some understanding of good paths, to the rest of us. By providing sequences for the smooth unfolding of applications, they could reduce pain for everyone, reduce inefficiency on a global scale, and help to move computing forward. But to evaluate their work, they will need to provide narrated, polished developmental sequences, free of the noise of first passes and repairs.

Note that progress in modern medicine and biology could not proceed today without studying the long sequences of steps in the unfolding of living systems. We need to do research in this dimension. Development is studied more in the world of chess (through the distribution and stepwise analysis of superb games) than in the world of software development.

I propose to write an open-source tool tailored to individual and collaborative viewing, writing, study, annotation, polishing, presentation and cross-referencing of sequences of program development. It will be hosted here, as a public repository of sequences.

The result will be full and partial sequences, by many authors, of well-worn, good developmental steps, which maintain coherence, simplicity and beauty at each stage, which make best use of a platform's functionality, and which lead smoothly to a final robust system.

The idea is to engender the production of as many excellent reference sequences as possible, continually improving them, to aid progress in engineering methodology, and to discover and propagate best practices in particular environments. I assert that it is nearly impossible to judge the positive effects of new "best practices" without seeing a developmental sequence or trying the proposed practices yourself.

A polished programming sequence demonstrates the unfolding of a good program. It is not simply a record of some programming journey. It is a reworked, recapitulated effort, demonstrating how the program should have been done, based on knowledge of the solution space for that platform, and on lessons from exploratory versions of that application. Results from other fields have shown good sequences to have a generative effect on people, enabling the design and creation of things not described in the original sequence.

I've written a first sequence. In my mind, it's of average quality. It provides 11 steps to a coherent yet trivial application for the Google App Engine (GAE) hosting environment.

Although we could write sequences about anything, for the moment I'd like to focus on the GAE platform. This is partly because it gives us a head start as a reference model, giving these sequences a live, standardized reality check, which would otherwise need to be constructed for other engineering environments.

Creating this tool, and using it to present a reference sequence for its own development, with the necessary restarts, introspection, and expert intervention, may take some time. I'm using this wiki as a kind of weak prototyping tool, to show how the first sequence might be presented in a viewer. Please look at it, and send me comments.

I can be reached at:



Project History

Here's the original article although the multi-page version of sequence 1 conveys a better sense of the what is proposed here.

This proposal and sequence is a recasting for engineering, and software engineering in particular, of ideas presented in published work by Christopher Alexander, who has spent decades experimenting with sequences to facilitate user-design, in the built environment. Based on this work, Alexander and I created a computer-based design tool, also for the built environment, in 1996-1997. That research was sponsored by Bill Joy, while he was with Sun Microsystems.

Goals for Developmental Engineering

The immediate goal of any reference sequence is to make it easier for a programmer to create good programs in a new environment.

The intermediate goal is to make it possible to maintain the coherence of increasingly complex systems, typically for a particular platform.

The long-term goal is to understand the improvements we need to make to programming environments, to allow smoother unfolding of robust, coherent, complex systems.

Using Generative Sequences

Good developmental sequences can be used to generate new programs in at least the following ways:

* Internalization

A person can follow a sequence as a tutorial, internalizing Important dependencies and developing an appreciation for good emerging structure. This will improve any program they subsequently generate.

* Substitution

A good sequence can be used in real time as an inspiration for the development of something entirely different, by appropriate substitution at each step, mutatis mutandis. While this mimicry is quite powerful, it's a rather advanced use, so the closer a generative sequence is to the new problem, especially regarding engineering platforms, the more broadly useful it will be.

* Addition

With many sequences to look at, especially on the same platform, the tendency is to see the commonalities among them, to see the important dependencies, to add snippets of one to snippets of another which, along with original exploration, makes a new product altogether. These new findings can then be passed to other programmers, for example with our proposed social-networking sequence-writing-viewing tool, by creating and naming the paths that link together the various sub-sequences.

* Abstract sequences

If enough smooth sequences for a platform are created, it is possible to create a useful abstract sequence, for any application. The programmer will leave out steps and borrow material elsewhere, as needed.

Fit with Current Paradigm

The reason Christopher Alexander wrote The Nature of Order, was to bridge the gap between patterns and the production of good structure. Patterns are generic good resolutions, but by themselves do not indicate how to create something wonderful, something alive, or something complex that works extremely well. It's very easy to use a good pattern in an average way, even if you take to heart everything about small, gradual improvements. Sequences, and the understanding of emerging centers, can help people understand how coherence works in natural systems, and how to make human work equally smooth, natural, and robust.

From a programming standpoint, patterns are good ideas, mined from software. Incrementalism allows you to start to produce quickly, and make small changes based on shifting priorities. Refactoring and extreme programmign encourage rigorous efforts to improve code, working towards the good ideas expressed in patterns. The Sequences of developmental programming are guides to improving the real-time smooth emergence of coherent applications. Sequences contain those dependencies and developmental steps that create and maintain good structure, as much possible, at each step in the morphogenesis of a system of software.

Because we studied it together so extensively, I take Alexander at his word -- each step in a sequence must reflect the fifteen properties as much as possible, in order to be good. By following this approach, although it may be difficult, we will come closer to understanding the brilliant engineering that takes place in nature.

On the name "core memory"

Since I'm using natural metaphors here, clearly the sequences in a genome are mostly stored in the nucleus of a cell. What would be the nucleus, the repository of fundamental sequences for software engineering? For decades the phrase "core memory" had a double meaning: not just reflecting the engineering trick of using magnetic cores, but also labeling the central working storage of a general purpose computer. Hence, this is a "core memory" for computing itself: open source sequences, for improving the work we do, as quickly as possible.

On these "bryagrams"

The expressionistic diagrams on each step are attempts to draw the metaphor further, maintaining a life-like structure for each step. I make use of our understanding of the nature of living, large-scale morphology at each major differentiation stage, during the epigenesis of a multicellular organism. I believe these kinds of diagrams, taken much further, will be extremely important for the developmental design of complex systems by people, as we borrow increasing numbers of engineering ideas from nature.

Comments