Failing to crack CABE's design code confusion
I left last week's masterplanning symposium thinking design coding more or less inevitable and, because of that, even more curious why CABE's recent 'Design Coding' reads like an inconsequential and hastily written end-of-term paper;
agonising over definitions, for example, before deciding on the term design code 'in recognition of the fact that it is a product derived from the consideration of relevant issues at a variety of different scales'. Ugh.
It avoids asking or answering basic questions but is keen to summarise, omit footnotes and list references without evidence of them having been read.
Granted, the Western Australian government's 'Liveable Neighbourhoods Community Design Code (LNCDC)' is not a snappy name, but it does convey the goal and the yardstick by which success or failure will be judged.
Compare our abstract 'Design Coding' - the stated goal of which is to codify design, something 'LNCDC' isn't concerned with as: 1) it's not prescriptive;
2) all recommendations needn't be complied with as long as the principles are incorporated; 3) it's offered to developers as an alternative route to the existing planning system; and, as a result of that, 4) facilitates comparison throughout its trial. What we're presented with, though, is four possible mechanisms by which design coding can be incorporated into the current planning system but no explanation why it has to be. We get seven pilot projects but no control against which to evaluate them.
Its thought processes are governmentally opaque, and key terms like 'design', 'code drafting' and 'code writing' governmentally elastic. We're repeatedly assured that people who write the code aren't the ones who design, and that the 'code' is drafted by individuals key to the design and delivery phases of the project - sometimes including code writers, sometimes not. Despite this, you conclude that 'key personnel' and 'technical experts' are the same - that they draft the code and then hand it over to the code writers to write or encrypt.
You never find out where or when the magic gets input, or by whom. It's not architects, as they're never mentioned, and it's not designers, for they've become code-testing collaborators. It's when CABE says a code is only as good as the people who write it that you realise code writers have been drafted in to take the blame, should the anticipated magic fail to appear or enchant. Towards the end, when defining a process of design coding is floated as a possible future development, you can't help thinking it's already an art.
Graham McKay, London SW11