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.

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.