[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Not using mixed content? Then don't use XML
- From: "Simon St.Laurent" <simonstl@simonstl.com>
- To: xml-dev@lists.xml.org
- Date: Mon, 25 Mar 2013 13:43:44 -0400
On 3/25/13 1:25 PM, Peter Ring wrote:
>> That in no way justifies the "constraints first" model that has dominated
>> markup conversations for the last three decades.
>
> There is a saying among industrial designers: "The Problem Comes
> First". Modelling and developing in terms of driving forces and
> constraints is central to design activity as a profession.
Resolving forces and constraints is what design activity does, yes. The
questions are more about timing and control.
> Christopher Alexander drew attention to the similarity between
> solutions that also shared a similarity between driving forces and
> constraints. In other words, your problem is most likely not very
> unique. And the solution will likely be a variation of an established
> pattern.
I fear that you've chosen the wrong expert - Alexander is actually one
of the key people to have explained to me why software's borrowing of
the architect model is poison.
From The Production of Houses (1985):
"The great complexity needed by a human settlement cannot be transmitted
via paper; and the separation of functions between architect and builder
is therefore out of the question. The complexity can only be preserved
if the architect and contractor are one. All this makes clear that the
architect must be the builder.
And the opposite is true also. In modern times, the contractor and his
crew are deeply and sadly alienated from the buildings they produce.
Since the buildings are seen as "products," no more than that, and since
they are specified to the last nail by the architect, the process of
building itself becomes alienated, dessicated, a machine assembly
process, with no love in it, no feeling, no warmth, and no humanity.
...it is axiomatic, for us that the people who build the houses must be
active, mentally and spiritually, while they are building, so that of
course they must have the power to make design decisions while they are
building, and must have an active relation to the conception of the
building, not a passive one. This makes it doubly clear that the
builders must be architects (74-5)....
Let us imagine building five hundred houses. In today's normal method
of building large-scale housing projects, one architect and one
contractor often control a rather large volume of houses or apartments...
The architect-builder... has greater powers but more limited domain.
Any one architect builder may control no more than twenty houses at a
time, but he will take full responsibility for their design and
construction, and he will work far more intensely with the individual
families, and with the individual details of their houses. Thus, in this
model of construction, both design and construction are decentralized....
Of course, this means that the architect-builders play a different role
in society. There are more of them - taking the place of the alienated
construction workers and architectural draftsmen who now provide the
manpower to make the centralized system work...
We envisage a new kind of professional who is able to see the buildings
which he builds as works of love, works of craft, individual; and who
creates a process in which the families are allowed, and even
encouraged, to play their natural role in helping to lay out their
houses and helping to create their own community. (76-78)"
Now, he may have stolen the idea roughly from Ruskin, but that isn't a
"design a fixed schema and then let everyone go implement it" model.
> Now, given that you've had the luck (ie wise management) to actually
> understand what the problem is about (business value, workflow,
> culture/habits, legacy, strategy, etc etc), how often would you need
> to start from first principles? And, even if you need to develop a
> vocabulary from scratch, how much trouble would it be to document your
> vocabulary in terms of your problem space? maybe even give it a name
> and a version, so that you don't introduce yet another invisible
> global state into your business processes?
The problem is less about the design of the vocabulary, and more about
the structures we've built around having experts design the vocabulary
first.
Thanks,
--
Simon St.Laurent
http://simonstl.com/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]