malvasia bianca

I’m in the middle of reading A New Theory of Urban Design. Not one of Alexander’s best (though it’s interesting enough); it’s hurt by problem that, as he comments, part of the theory that he’s discussing “remains unpublished. It will appear in a later volume of this series, “The Nature of Order”. Which turned into four volumes, of course, but who’s complaining? At least he’s avoided the Grothendieck problem (hardly unique to Grothendieck, of course) of publicly sketching out grand plans of future volumes which then divide further and remain unfinished. (Or maybe he has sketched out many future volumes, and I’m just unaware of it.)

The book presents the following “Overriding Rule” of design:

Every increment of construction must be made in such a way as to heal the city. (p. 22)

This gets recasted as follows:

Every new act of construction has just one basic obligation: it must create a continuous structure of wholes around itself. (p. 22)

He then talks about how each piece of construction affects the field of centers of the work: each increment should simultaneously work to support some center larger than itself, while fitting in with the adjacent centers and being made up out of smaller centers. (The notion of “centers” gets explained in The Nature of Order.) Which is an interesting way to think about programming: can we program in such a way that every chunk of code that we write heals the code base, developing a harmonious interplay of centers?

As in all of his work, this design is done collaboratively and incrementally. Which are both ideals that are dear to XP’s heart. Except when they aren’t. You can talk about a program’s design in terms of either how it behaves towards the programmer or how it behaves towards the user. The former sort of design is done collaboratively and incrementally; the latter is done incrementally, but isn’t done collaboratively. Instead, XP says that there should be a Customer speaking with a single voice, either being a single person or being filtered through a single person.

Why is this? And do I think it’s a good idea? To start with the latter: my tentative answer is no. If I’ve drunk the collaborative kool-aid elsewhere, I don’t see why I shouldn’t drink it here; if a city can be designed collaboratively, then surely a piece of software can be as well?

But if I accept that, then why might XP propose otherwise? (Of course, I could just be wrong about XP.) My tentative answer is that is has to do with XP’s programmer-centric nature: it’s focused on having programmers deliver as much value as possible to others. Given that, it concentrates on the details of how to program (pair programming, refactoring, etc.) and how to make sure that the software that is being written has highest business value (the planning game). But it doesn’t address the question of how the stories are generated and selected – that’s the Customer’s job. Given that story generation/selection is out of scope of XP, it proposes the simplest thing that could possibly work as a programming/Customer interface, namely a single-voiced Customer, and leaves it at that.

I wonder what an effective process with collaborative design on the Customer side would look like? This may be one of the potential advantages of processes where the programmers are the ones actually designing the application – it brings more design minds to the table. (Not that programmers designing software doesn’t have its own flaws, to be sure.)

Of course, one potential problem with multiple designers is a lack of coherence: nobody likes design by committee. Alexander has been tackling this problem heads-on for decades: that’s what pattern languages are all about, after all. (Well, one of the things that they’re about.) There are some interesting additions on that subject here as well. The book discusses an experiment at imagining how a section of a city might develop incrementally, through a series of projects. Each project has a different owner, so collaborative design comes into play for the city as a whole. But each project has one person leading it, and must come with a vision:

Every project must first be experienced, and then expressed, as a vision which can be seen in the inner eye (literally). It must have this quality so strongly that it can also be communicated to others, and felt by others, as a vision. (p. 50)

So that’s the tightrope that Alexander is walking. He tries to get the good aspects of individual design by having each design step be guided by a clear vision. That vision can guide other people working on that project, so the project doesn’t lose coherence. Next, other people working on subsequent projects have to try to maintain the coherence of the preceding visions (and open up the possibility of following visions), working so as to always heal the city.

Works for me. (And works a lot better than Metaphor.) It’ll be interesting to try to carry it out in practice, though.