Introduction
Statistics
Contact
Development
Disclaimer
Help
2018-06-13
__T_h_e__T_i_m_e_l_e_s_s__W_a_y__o_f__B_u_i_l_d_i_n_g_______________
uring my vacation I came to read Christopher Alexanders excellent
ook "The Timeless Way of Building"[0]. It describes (the following
s oversimplified) a generative way of describing architecture so
hat the built results are places where people enjoy being in, they
et used in the intended way and have a 'quality withouth a name'
ttached to them that make them beautiful, practical and enjoyable.
n contrast most modern architecture seems to be ugly, uninhabitable,
oring, depressing. One reason for this according to Alexander is the
issing connection between the architect's pattern langugage and the
eople inhabitating, building and using ta house or town.
ld buildings seem to connect all people involved to create a thing
hat's unique and built specifically to meet the needs and
equirements for its inhabitants and the location. This is done by
nterpreting the patterns and adapting their variety to the local
eeds. Hence all parties need to be involved.
o this seemed to have inspired people to carry the notion of
enerative patterns that create inherently good things over to
oftware. And that's where we see them as 'design patterns'.
find that metaphor a bit stretching but it seems Alexander got
nvited to give a keynote speech on OOPSLA 1996 [1].
here one finds that both parties Alexander and the SW community
ren't on the same page. He gives the following caveat in his speech:
When I look at the object-oriented work on patterns that I've
seen, I see the format of a pattern (context, problem, solution,
and so forth). It is a nice and useful format. It allows you to
write down good ideas about software design in a way that can be
discussed, shared, modified, and so forth. So, it is a really
useful vehicle of communication. And, I think that insofar as
patterns have become useful tools in the design of software, it
helps the task of programming in that way. It is a nice, neat
format and that is fine.
However, that is not all that pattern languages are supposed to
do. The pattern language that we began creating in the 1970s had
other essential features. First, it has a moral component. Second,
it has the aim of creating coherence, morphological coherence in
the things which are made with it. And third, it is generative: it
allows people to create coherence, morally sound objects, and
encourages and enables this process because of its emphasis on the
coherence of the created whole.
I don't know whether these features of pattern language have yet
been translated into your discipline.
o apart from the benefit of being able to reason about design using
attern language other qualities should be present at the same time.
nd this is were the metaphor is ending for software, even today.
here is hardly any moral aspect in today's design language. The UX
olks have a start when discussing manipulative or deceptive design
ut there aren't any patterns for good design so far.
he patterns don't strive for coherence with the things they are made
ith. Software is not written for a single purpose (other than to
enerate revenue in most cases...) and hardly with the user in mind.
nd noone really cares about the generated whole. Maye in closed
ystems like Apples this was more dominant than in others (iPhone UIs
ome to mind). But with ubiquitous web interfaces this is not the
ase anymore.
lso another pattern langugage rule that's violated with software
atterns is: They have to be simple and widerspread known and can be
nderstood by anyone. If it is not easy to tell people orally, it's
ot a pattern. I think the design patterns that fill our bookshelves
ill most likely fail in this regard.
aybe they are too low level. Hardly anyone trying to get work done
ith a piece of software cares about the singleton factory facade
nderneath.
lso Alexander argues that to test a pattern language one should
enerate designs (or 'play out' designs) from the language and
valuate those to fitness of the requirements. I am not aware of any
ethodology in SW design that does this. SW patterns are somewhat
assed around as the given solution to a problem but there's no way
o check whether the whole design will make sense.
e need an easier language to describe our designs and design
ecisions. We need morally sound software. Software that service
eople, do not betray them and are clear in what they do.
still think a pattern language is helpful to specify and argue
bout design in software. How should a language like this look like?
ho should be formulating the requirements?
think programmers will need to close the loop and distance between
hem and the users. This has been said many times of course and
eople are arguing whether everyone needs to be a programmer.
think that's a bit of an exaggeration. Not everyone needs to be a
rogrammer. But everyone should be able to discuss design and this
ncludes software design. So the next step in our evolution would be
o relearn a language that allows us to formulate designs in a way
ther humans will understand and are able to evaluate.
uch like everyone used to be able to tell a builder what a good
ouse / barn looks like for them. The builder can handle the
ecessary technical details and choose the tooling but the outcome
ould be inspectable and also up for discussion.
think a way to accomplish this is to abandon a lot of stock
oftware and return to building tiny pieces tailored to individual's
eeds. If needs change tools must change too. Like moving into
nother building or rebuilding a house to fit the new needs of a
rowing or shrinking family.
have no idea how this would work in practise, but let's build
mall, working things for people we know and care about. That may
ontribute to a better software world too.
__References________________________________________________________
0]: gopher://gopherpedia.com/0/The%20Timeless%20Way%20of%20Building
1]: http://www.patternlanguage.com/leveltwo/archivesframe.htm?/leveltwo/../arch…
