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_______________

During my vacation I came to read Christopher Alexanders excellent
book "The Timeless Way of Building"[0]. It describes (the following
is oversimplified) a generative way of describing architecture so
that the built results are places where people enjoy being in, they
get used in the intended way and have a 'quality withouth a name'
attached to them that make them beautiful, practical and enjoyable.

In contrast most modern architecture seems to be ugly, uninhabitable,
boring, depressing. One reason for this according to Alexander is the
missing connection between the architect's pattern langugage and the
people inhabitating, building and using ta house or town.

Old buildings seem to connect all people involved to create a thing
that's unique and built specifically to meet the needs and
requirements for its inhabitants and the location. This is done by
interpreting the patterns and adapting their variety to the local
needs. Hence all parties need to be involved.

So this seemed to have inspired people to carry the notion of
generative patterns that create inherently good things over to
software. And that's where we see them as 'design patterns'.

I find that metaphor a bit stretching but it seems Alexander got
invited to give a keynote speech on OOPSLA 1996 [1].

There one finds that both parties Alexander and the SW community
aren'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.

So apart from the benefit of being able to reason about design using
pattern language other qualities should be present at the same time.
And this is were the metaphor is ending for software, even today.

There is hardly any moral aspect in today's design language. The UX
folks have a start when discussing manipulative or deceptive design
but there aren't any patterns for good design so far.

The patterns don't strive for coherence with the things they are made
with. Software is not written for a single purpose (other than to
generate revenue in most cases...) and hardly with the user in mind.
And noone really cares about the generated whole. Maye in closed
systems like Apples this was more dominant than in others (iPhone UIs
come to mind). But with ubiquitous web interfaces this is not the
case anymore.

Also another pattern langugage rule that's violated with software
patterns is: They have to be simple and widerspread known and can be
understood by anyone. If it is not easy to tell people orally, it's
not a pattern. I think the design patterns that fill our bookshelves
will most likely fail in this regard.

Maybe they are too low level. Hardly anyone trying to get work done
with a piece of software cares about the singleton factory facade
underneath.

Also Alexander argues that to test a pattern language one should
generate designs (or 'play out' designs) from the language and
evaluate those to fitness of the requirements. I am not aware of any
methodology in SW design that does this. SW patterns are somewhat
passed around as the given solution to a problem but there's no way
to check whether the whole design will make sense.

We need an easier language to describe our designs and design
decisions. We need morally sound software. Software that service
people, do not betray them and are clear in what they do.

I still think a pattern language is helpful to specify and argue
about design in software.  How should a language like this look like?
Who should be formulating the requirements?

I think programmers will need to close the loop and distance between
them and the users. This has been said many times of course and
people are arguing whether everyone needs to be a programmer.

I think that's a bit of an exaggeration. Not everyone needs to be a
programmer. But everyone should be able to discuss design and this
includes software design. So the next step in our evolution would be
to relearn a language that allows us to formulate designs in a way
other humans will understand and are able to evaluate.

Much like everyone used to be able to tell a builder what a good
house / barn looks like for them.  The builder can handle the
necessary technical details and choose the tooling but the outcome
would be inspectable and also up for discussion.

I think a way to accomplish this is to abandon a lot of stock
software and return to building tiny pieces tailored to individual's
needs. If needs change tools must change too. Like moving into
another building or rebuilding a house to fit the new needs of a
growing or shrinking family.

I have no idea how this would work in practise, but let's build
small, working things for people we know and care about. That may
contribute 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/../archives/ieee/ieee.htm