↑ beautiful.software
      
transcript for
Unfolding Sequences - an introduction
by Greg Bryant
on the urbanology channel

      
Smoothly unfolding sequences
Which of the things that we make are good?
Which are beautiful?
Which are wonderful, coherent, clear, natural, and full of life?
Good work may be hard to describe in words, but we know how it makes us feel.
So how do we create work like that?
And how can we make the act of  working, the process of working itself,  
something that's smooth, comprehensive, flowing,  
focusing, comprehensible, reliable, well-informed, rich and rewarding, personal and pleasant?
And if we figure out how to do all that, how can we explain it to people,  
and empower them to do good work?
An architect, scientist, and Berkeley Professor, Christopher Alexander, spent  
decades trying to answer these kinds of questions.
He found that the most useful places to look for answers were, on the one hand, in traditional  
communities, that build their own structures in harmony with their lives, and on the other hand,
in living organisms, which produce by far the  most beautiful and complex systems on the planet.
Alexander publicly explored these  questions in the realm of architecture,  
art, and urban planning, starting in the late 1950s.
But, surprisingly, his work had a regular impact on the way computing has progressed.
An insanely prolific impact.
Structured programming, structure decomposition, design methods, object-oriented programming,  
software patterns, pattern languages of programming, incremental improvement,  
extreme programming, scrum, agile, continuous delivery,  
life cycle management, user interface and user experience principles and design tools.
All these, and many more, were influenced by a series of groundbreaking books by Alexander.
Even the wiki was invented to store patterns as Alexander defined them in his classic book 'A Pattern Language'.
And his work influenced countless successful products from Java's first frameworks, to SimCity, Spore, and The Sims.
But in his core research and practice, Alexander was not completely satisfied 
with the quality of the work that people do by using only patterns, user-directed design,  
incremental construction, and pattern languages.
He knew, early on, that these tools were not sufficient to energize people to generate truly wonderful work.
There was something else required.
A feeling, an innate sensibility and appreciation for life, which people need to find within themselves.
One of the best contexts for discovery  and use of this sensitivity were tools that I like to call:
'Smoothly Unfolding Sequences'.
In this context, 'sequences' means a series of prioritized steps that an experienced  
designer or engineer or builder would take so that they, and their colleagues,  
and their users, could together build the most well-adapted, custom, beautiful thing possible  
in the smoothest and most robust way possible, together making the best decisions,
and adjusting the growing system to changing conditions, revealed facts, and emerging structures,
at every stage in the development of their project.
Within specific domains, done properly, these sequences could be tested,  
debugged if you will, smoothed out, and corrected, until they could be used repeatedly,
and people who experienced them could use them for new kinds  
of projects, once the general principles, as expressed by the sequence, were understood.
Or, they could write new sequences.
Overall, after much experimentation during many group projects,  
Alexander concluded that these natural sequences significantly improved communication,  
process, and satisfaction with the resulting quality, in any domain.
But this result, which could be considered Alexander's next big idea,  
has not yet been adopted by the computer industry.
So, what might that be like?
Imagine you have a technology stack.
You want people to become good at using it.
You get your best people together to make a complex product, 
one they know quite well how to build with your stack.
They write a special kind of plan for building this product, which we'll call a sequence.
They now build it, following this sequence.
But, of course, it's not quite right, so they correct the sequence.
You're left with a product, and an unfolding sequence.
Then this, or another, group tests the resulting sequence, building the product again.
Eventually you have a well-debugged 'example  unfolding' of a complex product with your stack.
If the sequence is really good, anyone who follows it will be using an  
expert guide to making any application with that stack.
At the same time, problems with the stack itself will become apparent.
You can then make other sequences, if there are different kinds of approaches to making use of your stack.
In 1996, Alexander and I embarked on building a psychologically effective computer program  
that would facilitate some complex design work.
The user would be guided by just this kind of evocative,  
smoothly unfolding sequence of suggestions about the kinds of structures that should be emerging,  
by their hand, at a series of important stages.
Thanks to a grant from Bill Joy at Sun Microsystems  
we had our first real successes with it in  1997. The program was called 'Gatemaker',  
and we gave it to people who had no idea how to design a good gate.
Here is a recording of musician Peter Gabriel making use of the sequence.
The result has been natural and satisfying for everyone who has been guided to use it.
Sequences may turn out to be the best way to communicate ideas about  
the design and development of anything complex.
The authoring of good sequences records institutional and community knowledge,  
in a way that increases quality and reduces risk in future projects.
Unfortunately the dot-com boom and crash interfered with our initial work.
But we've discovered many important things about unfolding sequences,  
over the years, which we would like to share with people.
We believe everyone will find that they feel ... very familiar.
In the description below read more about how to join us, and where we're going.