Embedded Files
by Greg Bryant
February 5, 2009
On this site, I hope to introduce a new kind of investigation to the various engineering disciplines of computing: the study of generative unfolding sequences.
An unfolding sequence consists of ordered stages in the development of a particular program, in a particular environment. A good sequence demonstrates an idealized smooth unfolding of a program, with steps describing the emergence of structures according to their relative importance to the whole: from the most fundamental structure to the least. Each step also describes global changes, across the entire system (even though this might result in just one low-level local change) in order to keep the result coherent and the principles broadly-applied.
Although sequences describe specific projects in specific contexts, they also inspire new work, and so can be doubly described as generative. Through the use of sequences as a medium, we can discuss the effectiveness of a given process and development environment more easily. And we can better communicate good form to programmers unfamiliar with a given environment.
Good sequences can only be written by recapitulating a particular programming effort, more than once, after experiment and exploration. A good sequence does not back-track or refactor, something that is possible only because of this recapitulation, ensuring that solutions, once found, are integrated back into their appropriate place into these 'canonical' sequences. As a result, each small step describes the emergence of a structure of the appropriate scale, introduced at the right stage in development, contributing to the coherence of the final system.
By following the guidelines below, sequences can convey fundamental ideas in a precise way, identify systemic problems with approaches and environments, and lead to massive improvements in entire categories of engineered systems and development environments.
I present a working example below: Sequence 1. I'm using Google App Engine as a reference platform.
To assist us in continuing this fundamental research, my team is available to write sequences for any technology, on a contract basis. I can be reached at:
Guidelines for Sequence-writing
1. In general, try to order the sequence by the approximate weight and importance of the structures described in each step, along a gradient, from the most fundamental to the least. To determine whether a structure deserves an entire step, or just a footnote to a step, consider whether, as a step, it's of a scale that fits smoothly into the gradient, between the steps before and after it.
2. Make sure that each step creates good organization for all the steps that follow. In this way, each step is global, good for the whole program, so the result will be coherent, robust, comprehensible, balanced, and natural.
3. Write a title for each step, a noun-phrase that describes something in the application that first emerges at that step. This should be something that remains in the application, so the statement it still true at the end of the sequence.
4. Write a description for each step, which is declarative, which is not an instruction, and which does not refer to the stage explicitly, but which describes the structure in the title, in a way that would, again, be just as true in the finished application.
5. After this, describe the implementation for the step -- get chatty: explain the construction, the context, and the code, along with tricks and tips. In the title and description, it's bad form to tell people what to do. But in the implementation section, it's fine.
6. Make sure the structure described, at each step, is in harmony with that of the previous step, yet moves strongly forward: so, no back-tracking, no refactoring. This is not a diary of one exploratory programming adventure. It is a narrative of the best development sequence you can produce. This is a chance to get things right, not just in the final product, but in the way the product emerged. If you wrote the same program many times, taking advantage of what you learned, what would you do differently? Show us, after all this exploratory programming is done. Imagine you are an adventurer, an explorer, and you are writing down the best directions possible, so people can follow you.
7. Some of your steps may not seem very elegant, because they are needed to compensate for limitations in the computing environment. Make these as clear as possible, so the next iteration of that development environment can improve.
Note that 1, 2, 3 and 4 give sequences their generative quality, and engender a balanced view of the whole system.
Origins
Patterns, wikis, incremental programming, extreme programming and much more, were inspired by the work of builder and architect Christopher Alexander. So too with sequences.
In his own journey to discover how to build better places, and to help others create those places for themselves, Alexander found that pattern languages and incrementalism were helpful, but not sufficient.
But, over time, he discovered an approach that was sufficient. He tested this approach with thousands of people over many years, and their results were consistently superb, complex, coherent and robust. We have not adopted the approach in computing, yet. It makes use of a particular set of human sensibilities, and one key communication tool: the generative unfolding sequence.
In 1996 Alexander and I embarked on a project to create a CAD tool to facilitate the use of these sequences. With our first internal release, we polished a small sequence of 17 steps, which allowed the user to build something very personal, in a landscape: a gate in a garden. The results were excellent, generated by users who were completely unfamiliar with landscape design, and far surpassing the quality of work to be found in most of today's professional landscape efforts. The power of good sequences was abundantly clear to us.
Sequences are applicable to the creation of better programs. Unfortunately, at the time, we all became somewhat distracted by the dotcom boom. But I've kept an eye out for a good opportunity to revive this line of fundamental research. I call this site "core memory" because these sequences are so reminiscent of DNA, the threads of memory at the core of living systems. And because a collection of ever-improving sequences could become a central repository of computing knowledge.
The 1996-1997 work was sponsored by Bill Joy, with additional help, before and after, by Doug Carlston, Adele Goldberg, Mike Clary, Richard Gabriel, Stewart Brand, Jim Coplien, Kent Beck, Will Wright, Peter Gabriel, Josh Gordon, John Gage, George Williams, Ron Goldman and many, many others.
Page updated
Report abuse