Sustainable Design
In my most recent IEEE Column, Creating Sustainable Designs, I explore what it means to create software that can be maintained without too many growing pains. I have been intrigued by Christopher Alexander's writings, particularly the first two volumes of the Nature of Order where he explains the properties of designed (or architected) things which have life and processes for creating life.
It is just as important to look at process of creating good software as it is to consider what properties make software habitable for those who have to maintain it and keep it alive. While I appreciate process (and I think the agile community has given us a lot to consider) I am more keenly interested in exploring what makes complex software "living".
Alexander identifies these properties (or qualities) of living things: levels of scale, strong centers, boundaries, alternating repetition, positive space, good shape, local symmetries, deep interlock and ambiguity, contrast, gradients, roughness, echoes, the void, simplicity and inner calm, and non separateness.
It can be easy picking to draw certain connections between certain "good" software design properties and Alexander's list. For example, good shape, as others have pointed out can be a matter even as simple as properly indented a method. Or it can be more profound than that--leading you to break up a method into substeps and invoke helper methods, just to keep every step at a similar level of abstraction. I'm only giving you a taste to see whether you are interested in exploring these ideas further.
If you are, read my column, and also take a look at the C++ Report article by Jim Coplien on Space: The Final Frontier, which introduces Alexander's notion of centers and how they relate to software structure, and peruse several very good blog entries by Regis Medina.
And if you are interested in exploring these ideas further, perhaps by taking a deep look into working code or frameworks or software that you consider to be particularly alive (or not)... let me know. I am considering finding a venue where software developers and designers and philosophers could concretely explore Alexander's properties more thoroughly. I am not just satisfied to make those simple, easy connections and call it good. I want to challenge our best designs and see whether Alexander's properties really do apply (or if we have some other properties that are more relevant).
posted by Rebecca Wirfs-Brock at
8:12 AM
4 Comments:
The general notion of centres has something to it, but there is a challenge in trying to apply the fifteen properties literally to code and software abstractions. They seem to have something to offer us in describing physical forms, but for things of a more abstract nature we need to be careful with any notion that they offer us something objective and independently verifiable. When we move away from the relative concreteness of code layout, things get particularly murky and subjective.
It is all too easy to be selective in seeing where they match, and failing to see where they do not match and, therefore, contradict our assumptions. This is the common problem of confirmation bias.
For example, in addition to seeing them in a positive light, we can also see deep interlock and ambiguity as the bane of legacy code, alternating repetition as code waiting to be refactored and good shape as a property of visualisation, which for abstract software structures is essentially arbitrary -- I can choose a visualisation that makes poor code look good or good code look poor.
So there is potentially something interesting here, but whether it is in hidden depths is not a foregone conclusion. It may just be something interesting lurking in the shallows!
Kevlin, I am in total agreement with the problems you describe in "selectively" making mappings from properties of life to "good" or "bad" things we see in code.
And I, too, have trouble saying whether all these properties are good for code and sw design or not. Alexander's properties are so, well, mystically, named that initially I found them a bit difficult to wrap my head around. But just like problem frames...there is something there if we go in as healthy skeptics and take a deeper look. For me the most important part of framing was in the kinds of questions it got me as a designer to ask. The frame types themselves didn't help me otherwise.
Frankly, I don't know whether what we'd find would help us understand why something is good any better than what we know now about sw...but I am still interested in making some meaningful connections.
I've been semi-obsessed with the first two volumes of The Nature of Order for a while, e.g. living code or agile processes as living structures (or even Shadow of the Colossus as living structure), so I've been happy to read your tweets on the subject and now this post and article. I was sorry to see that your Agile 2009 proposal on the subject was rejected, but I'd love to dive into it with you in the open space there...
David-
That's a great idea...we should definitely set up some open space time to talk about Alexander's properties and which ones seem to resonate with what agile designers do...and which don't.
I look forward to seeing you at Agile 2009.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home