ACCU2016: Talk on Software Architecture Design 2: The Historical Context

Posted on by

[This is the second part of the transcript of my talk at ACCU2016 entitled: “Software Architecture: Living Structure, Art, or Just Hopeful Arrangements of Bytes“]

An enlightening aspect that surprisingly pertains to the issue of software design is the philosophical history that has led us to our current technological society.

Batalla_de_rocroi
Looking back we can see some origins in the Thirty Years War that took place between 1618 and 1648. Some commentators have drawn parallels with the impact of WW1 and WW2 between 1914 and 1945, saying that they could also be seen as a thirty year war. (See the book “Cosmopolis” by Steven Toulmin) The Thirty Years War of 1618 was a terrible war over much of Europe that resulted in the death of a third of the German population. It was a religious war between Protestants and Catholics, i.e. one religion – two factions – and raised serious concerns about the subjectivity of religious faith and the human condition. It was this that brought the quest for certainty to a head. The underlying question was: How can we be certain of what is happening in the world around us? And for the faithful in the 1600s, how can we be certain of God’s plan?

Descartes

It was during this time that René Descartes produced his “Discourse on Method” in 1637. He was the father of analytical geometry and of course coined the famous phrase “I think, therefore I am”. But this was predicated on the fact that we first doubt, thus the more correct phrase should be “I doubt, I think, therefore I am”. He concluded that because of our subjectivity, we cannot trust our senses and what they are telling us about the world, so he returned to the point of doubting. Since there was doubt, there must be a being that is doubting. This being, this ‘I’, that is doubting is thinking about this so therefore I am thinking. Since I am thinking I must exist in order to do that thinking.

Because the church was looking for certainty and because Descartes was able to couch his thought in terms that they could accept, this provided the foundation for the Scientific Revolution. This was followed by the Industrial Revolution which has led us to our current modern technological society. It is interesting to consider the fact that all that we take for granted today represents the end of 300 years or so of work based on Descartes’ philosophical premise: “I doubt, I think, therefore I am” where the aim was to try and eradicate subjectivity.

It is ironic that, although the aim was to be objective, his Cartesian coordinate system can be considered to be based on the structure of the human being! I stand up, and my head could be considered as the Y axis. I stretch my arms out to the side, there you have the X axis. I walk forward and there you have the Z axis.

This points to the difficulties that are implicit in the struggle to eradicate subjectivity – an objective (pun intended!) which I do not consider possible.

Kant

I usually refrain from mentioning Immanuel Kant since I am not a Kanitan scholar, but his thinking has formed much of the basis of modern thought. He produced the “Critique of Pure Reason” in 1781, and there is one quote I wish to highlight here from his considerable body of work. He said that “The world in itself is unknowable”. and this strengthened Descartes’ approach of not trusting our senses. It has given our modern scientific and technological society the excuse to allow our thinking to run ahead of the phenomena of the world.

This activity may sound familiar if you think back to the Path of the Programmer. It is a characteristic of the Journeyman phase.

With regard to my previous workshop on imagination, an area dealing with educating our subjectivity, it is interesting to see that one commentator, Mark Johnson, has noted that Kant had difficulty with imagination – Johnson states that he was “not able to find a unified theory of imagination in Kant’s writings” (The Body in the Mind p166).

Goethe

The third person I want to mention, and the one I feel most drawn to, is Goethe. It was Goethe who raised the warning flag to say that there was a problem with the underlying philosophy and practice of the scientific method. He pointed out that there was too much over-hypothesizing and that the thinking was going ahead of the phenomena of the world. Observation was not being given enough time.

This should ring alarm bells for any programmer because it is exactly what happens when someone takes an undisciplined approach to debugging.

Goethe, however, was particularly interested in understanding the growth of plant life. He wrote the Metamorphosis of Plants in 1788 and identified two very important activities. The first one is Delicate Empiricism (or “Zarte Empirie” in German), i.e. carefully collecting the data, carefully observing the world without overly disturbing its processes.

The second activity, which is what gave me the impetus to give my previous workshop on imagination in 2014, is Exact Sensorial Imagination. This is NOT fantasy, but exact, grounded imagination congruent with the observed phenomena. Goethe was trying to understand how plants grew and how their forms changed during growth.

For me this links to how software projects grow over time, as if they have a life of their own. A programmer needs to have a grasp of how the current software forms may change over time within such a context if they are to minimise future bugs.

The key difference between Descartes and Goethe is that Descartes was trying to eradicate subjectivity whereas Goethe was wanting to educate subjectivity.

The next important phase in philosophical thought is the advent of phenomenology in the 1900s. The realization that the process of coming to know something is crucial to, and as important as, the conclusion. Goethe is not considered a phenomenologist as he focused on specific phenomena rather than the philosophy behind what he was doing, but he definitely prefigured some of their ideas and so could be called a proto-phenomenologist.

We need to understand that phenomenology is a sea-change in philosophical thought. Here we are, living in a modern technological society based on 300 years of progress initiated by Descartes and his subject/object duality, and now the underlying foundational thinking has changed significantly.

The discipline of software development in the forefront of trying to understand what this change of thinking means in practice, though it may not have realised it. We need to understand how we develop our ideas and we need to understand our own cognitive biases, the subject of Dr. Marian Petre’s keynote “Balancing Bias in Software Development“. The point here is that we can do a certain amount in teams but there is also some personal work to do in understanding our own learning processes.

There is a wonderful quote by Jenny Quillien who has written a summary of Christopher Alexander’s Nature of Order books. She says in a preface:

“Wisdom tells us not to remain wedded to the products of thought but to court the process.”
(Jenny Quillien Delight’s Muse)

I think this is a lovely way of putting it. The process needs courting, it has to be done carefully as with Goethe’s Delicate Empiricism.

For those who wish to understand Goethe’s work and the philosophical issues around phenomenology, a primary source is Henri Bortoft. His writing is very understandable, particularly his book “Taking Appearance Seriously” and he draws on the work of Gadamer, one of the more recent phenomenologists.

→ACCU2016: Talk on Software Architecture Design 3: The Issue of Doubt
←ACCU2016: Talk on Software Architecture Design 1: The Path of the Programmer

Phenomenal Software: The Internal Dimension: Part 2b: Patterns & Livingness

Posted on by

In this post I am going to review Alexander’s three aspects of patterns mentioned before, namely:

  • The Moral Component
  • Coherent Designs
  • Generative Process

I will show how they link to the following ideas:

  • Freedom
  • Cognitive Feeling
  • Livingness

The Moral Component & Freedom

20110916_1352_BuzzardThe moral aspect of patterns can be approached from any of a number of ‘paths up the mountain’. Certainly Alexander was concerned about whether buildings were ‘nurturing’ for us to live in, and so was thinking about more than utility. With computer systems and applications it is easier to think that this utilitarian aspect is all that exists. But there is an environmental part – an inner environment of thought, or ‘theory’ as Naur would say, whether we be users or developers.

If we think about how tools extend our own faculties, indeed our own being, the importance of the quality of this inner environment takes on a new meaning. The nature of the tool will affect how we form our ideas, which in turn will influence the form of our externally made world. Thus Alexander’s use of the word ‘nurturing’ and its applicability to software is not so out of place as it initially seems.

We can relate the ideas of utility, environment and hence morality by considering the concept of freedom – but defined in terms relevant to computer use. A computer system or application is a tool to get a particular task done. Good tools are ‘transparent’, meaning that you do not notice them when performing a particular task – they ‘disappear’ from your consciousness and leave you ‘free’ to focus upon the task in hand. It is in these terms that we can speak about freedom when using computers.

If you experience this ‘transparency’ when using a computer, I would consider that the software you are using contains this moral component that Alexander has defined. To paraphrase his words from the ‘Mirror of Self’ question:

“‘Moral’ Software gives you the freedom to develop a better picture of the whole of yourself, with all your hopes, fears, weaknesses, glory, absurdity, and which – as far as possible – includes everything that you could ever hope to be.”

What higher statement of purpose could we have for the programs we write? The current prevalent economic vision of the software industry pales into insignificance against such a statement.

We should not forget that this freedom to develop a ‘better picture of the whole of ourselves’ can be experienced by both users and developers. Indeed it is a central tenet of my whole ‘Phenomenal Software’ series that good software developers are implicitly on a path of self development, whether they are conscious of it or not.

Coherent Design & Cognitive Feeling

PetrelWingIn talking about coherent design we need to remember that Alexander is dealing with the external world of objects and a software designer/developer is dealing with non-physical artefacts – the building architect works in an external world, the software architect works in an internal world – though no less real in its effects.

If we consider programming as an ‘internal art’ we can see how it can be difficult to communicate effectively about the ideas that underpin our design and coding. Peter Naur wrote about the need to maintain a theory alive in the minds of the programmers if a system was to be properly extended or maintained. He also noted that the theoretical element could not be communicated accurately via written documentation or even the code itself – it needed human interaction with people holding the living theory of the software.

Reflecting on my own career I have come to realize that it is difficult to identify an abstract form of coherence or goodness for software separate from the context in which it is to be used. For instance some code that I had found to be elegant in the early days of computing, say using little memory and having few instructions, would not be a good solution to the same problem in a modern context. So here we can see the integration required between form and function; solution and problem context. They need to be in harmony: coherent form in design will have the moral component in its function and will mean that the theories and meaning formed by the developer or user will make sense and meet the ‘Mirror of the Self’ needs.

Most novices will work from a set of rules, one such example being to ‘Make it Work, Make it Right, Make it Fast’ in that order. This is a valid heuristic useful to stop programmers optimizing the code too early. However a rule-based approach has the danger of separating the stages into individual parts – which is not the best way to proceed in one’s thinking. This is the same tension as that between the TDD (Test Driven Development) folks and the design-up-front folks – a classic example of the need to work from an integrated view of the whole and the parts – i.e. respectively: making it right and making it work; design-driven and test-driven. In practice being done together.

So over my career I have developed a feeling for good design in the crucible of solving real-world problems. In actuality I cannot make it ‘Work’ until I have a sense of what is ‘Right’, even to a small degree. You can perhaps see that I have a personal preference towards the design view, though during my work I can easily fall into the trap of hitting the keyboard too early, something I have worked vigorously at controlling! As I gained experience I started to get this sense of the best way to structure the software, and in some cases – such as perhaps designing a media player – I might have a feeling for what is ‘Fast’ at an early stage, but this needs to be kept strongly in check against reality. Optimisation should be based upon measurement and human beings can be worse than random at predicting what needs optimising.

This sense for a good or coherent design is what I have called a ‘cognitive feeling’ in an earlier post, which is a very fine and delicate sensation indeed – it is not strong emotion. Over the years of my career I liken its development to the creation of a new sense organ, cognitive in its nature. It can be difficult to explain to less experienced practitioners due to the fact that the sense is likely to have been implicitly developed over the years. However it matches closely to the feelings that are evinced by Alexander’s ‘Mirror of the Self’ test so that frequently when talking to more experienced developers it will not be hard to get to a commonality in judgement.

This means that in order to create coherent designs we will need to develop this extra sense of a fine cognitive feeling. A quote from Alexander serves to give an idea of this feeling sense, and though dealing with external geometric entities, the same comments relate to software design when imagining how the structures will function:

“A pulsating, fluid, but nonetheless definite entity swims in your mind’s eye. It is a geometrical image, it is far more than the knowledge of the problem; it is the knowledge of the problem, coupled with the knowledge of the kinds of geometrics which will solve the problem, and coupled with the feeling which is created by that kind of geometry solving that problem.” A Timeless Way of Building, Chapter 9.

Generative Process & Living Structure

CloudTrailIn Alexander’s talk at the OOPSLA’96 conference in San Jose, he seemed somewhat bemused by the software domain’s use of patterns. On reading Alexander’s Nature of Order series we can perhaps see why. Some of the central ideas are those of ‘living structure’ and ‘structure preserving transformations’ which result in a ‘generative process’. How could these relate to software?

It is easier to understand the concept of structure preserving transformations when looking at how living things grow. As they grow and develop they need to continue living – we cannot just take them apart, do some modifications, and then re-assemble them! Every step of growth cannot disturb their livingness – thus EVERY change must preserve their living structure. The world of living things has no choice but to use a generative process if it is to stay alive.

At first glance this does not relate at all to the built world. When fixing my car in my younger days, there were times when bits of gearbox and engine were all over the floor! If the car had been a living being it would have been dead, but since it was not I of course was able to re-assemble it and make it work. Small software systems are similar. However, if you have ever worked on a sizable legacy system you will know that you need to spend a LOT of effort on NOT breaking the system. Any changes you make need to be closer to structure preserving, and any bad structures will need major surgery to improve. In reality you will not even try if it is not economically viable. Once you have bad structure, or use a ‘structure destroying transformation’ it is extremely difficult if not impossible to remedy:

“Good transformations do not cause any upheaval. So to get a good project, we merely have to make a sequence of structure-preserving transformations. When we do so, a good design evolves smoothly, almost automatically.
However, even a single bad transformation can upset the smooth unfolding. If we make one transformation which destroys structure, in the middle of a sequence of good ones, things become ugly very quickly;” Nature of Order Book 2 p61. See also chapter 4.
I am not sure about the use of the word ‘merely’ in the above, since it understates the difficulty of identifying good transformations.

Also if we accept Naur’s Theory Building view and the idea of human mental schemas, this idea of a generative process makes more sense, since there is the living theory held by the programmers. If we then go further and connect to the phenomenological ideas of how we create meaning when we develop theories we can see that there is a justification for finding a livingness within the programming activity. Bortoft talks about the link between understanding and meaning which relates well to Naur’s ideas of theory building when understanding software. It also gives another dimension to the idea of livingness:

“understanding is the ‘concretion of meaning itself’, so that meaning comes into being in understanding.” Henri Bortoft in Taking Appearance Seriously p108

Just one final thought about the idea of livingness. Some might think that a running program would have a livingness, especially if it was a big system. I am not so sure and consider that it is WE who provide the livingness in the software domain. It is WE who create; experience design pain; judge. The computers are running a network of finalized thought constructs which is a different process to the thinking we do when defining those thought constructs. For me this perception of livingness in Alexander’s work and its relation to software is an ongoing work-in-progress.

I want to thank Jim Coplien for his help in pointing me at various ideas of Alexander that mesh with my work for this post.

In the next post I shall conclude this series of ‘Phenomenal Software’ by returning to the way philosophy has progressed forward from the Cartesian Subject/Object view. This will mean dealing with the thorny subject of subjectivity and of course you will have to decide if you can trust my judgements!

Thanks for reading.

Phenomenal Software Development : Philosophical Interlude

Posted on by

Please note that I am not an academic philosopher (as evidenced by my use of the word ‘Dudes’ in the style of Bill & Ted’s Excellent Adventure!) In preparing this material I have drawn heavily on Henri Bortoft’s excellent précis of philosophical history in his book “Taking Appearance Seriously” which he also relates to current phenomenological thinking.

MothSideViewPhilosopher Dudes from History

  • Bacon (1561-1626)
    This is the man who used binary notation to ‘encrypt’ messages transferred around his network of contacts. He concluded that mathematics was the path to certainty and believed in the mastery of Man over Nature, both conclusions that Goethe subsequently disagreed with.
  • Descartes (1596-1650)
    One of the thinkers that has had the most impact on the current time. The founder of the subject/object dualistic way of thinking about things. I shall talk more about Descartes below.
  • Newton (1642-1727)
    The man who gave us those equations of motion I remember having to learn by rote at school. He used a disciplined imagination to propose mathematical models of reality. This then allowed scientists to solve problems within the mathematical realm and subsequently translate the solutions into a physical situation. This link between mathematics and reality is now something we take for granted and is a powerful tool without which we would not have the world we know today.
  • Goethe (1749-1832)
    Although perhaps known more for his artistic endeavours, Goethe was a natural scientist as well. Even back in the 1800s he was raising a warning flag about the scientific method and the problem of over-hypothesising and imposing these hypotheses upon reality. Although in everyday parlance this is the problem of jumping to conclusions, in science this concern has become clearest in the field of quantum physics. The most useful idea I find in Goethe is the metaphor of ‘conversation’ for any scientific research with phenomena. In this Goethe prefigured the coming phenomenological school of thought.
  • Husserl (1859-1938)
    The founder of phenomenology who highlighted the importance of focusing on the process of a thing appearing to us as opposed to the final result of the thing itself. A tricky distinction which I will come back to later.
  • Gadamer (1900-2002)
    Before reading Bortoft’s book I was not familiar with Gadamer’s work and the whole realm of the philosophy of meaning – hermeneutics. Apart from having to rush for the dictionary to check out these new words I relate strongly to the importance of meaning for us. Giving life meaning is something we do all the time, frequently without realizing it. My view is that as we begin to impose our meanings on the world we need to become aware of this aspect of our cognition. (Simon Robinson has produced a great review of Gadamer’s book Truth and Method)

That is the brief overview. Now I will contrast Descartes and Goethe to highlight how these points fit into the discipline of software development.

Descartes and Dualism

Descartes lived between 1596 and 1650. He wanted to be sure of what we could really know uncluttered by the input from our senses. The foundation that he found was the ‘rock’ that is our thinking – something we can be sure of. Then given that we knew we were thinking we could be sure that we were thinking with something, an element of our body.

This is how he came to identify this Dualism of the mind and the body, but it is important to realise that he also wanted to fit in with the church’s views at that time which held that the human being as composed of body and soul. Descartes wanted the church to accept the primacy of thinking. He succeeded in doing so which provided an acceptable foundation for the mathematics that became the basis for the Scientific Revolution. This Scientific Revolution then led to the Industrial Revolution which has created the world we know today.

An interesting point here is the language he used to describe the mind and body. The minds was ‘res cogitans’ – thinking, a verb. An active principle. The body was ‘ res extensa’ – extension, the body, a noun. A passive principle. This further consolidated the view of Francis Bacon that man’s mind was to be master over nature, the world’s body. However this point of view has significant negative consequences as we now know since it has led to many of the ecological problems we have today.

Descartes ideas and thought are firmly entrenched in software development, because software development is indeed an exercise in applied mathematics.

Goethe and Delicate Empiricism

Goethe was a natural scientist who was around at the time of the Industrial Revolution and he was against the Baconian approach of the separation of man from the natural world and the mastery of man over nature. He warned of the danger of over-hypothesising and recognised the need to focus on the phenomenon and not on abstract ideas. He realised that over-abstracting away from the phenomenon under observation could cause errors in understanding. He counselled against moving too far and too early into the realm of abstract ideas and coined the term Delicate Empiricism.

Delicate Empiricism is where the Observer needs to be aware of their own process of observation and how it affects their final conclusions. He also coined the term Exact Sensorial Imagination. Rather than indicating an ungrounded fantasy this is a disciplined process in understanding any phenomenon and how it exists, hence the used of the word ‘Exact’.

In software development we use this process all the time. Whenever I have to imagine how my software is going to work, or am trying to understand how it may be going wrong, I have to use this disciplined process of imagination to ‘run’ the software’s structures (concepts) in my head. If I am not exact then I will come to incorrect conclusions.

However Goethe only dealt with the natural world, not something that links well into software development. It was Rudolf Steiner (1861-1925), a Goethean scholar, who realised that the same methods could be used for the perception of our own thinking, i.e. treating our thought as a phenomenon in the same way.

At the point where we become aware of our own thinking processes when doing software development – something I consider to be crucial – we are treating our thought as a phenomenon. Thus as we observe our own thinking we are able to improve it and become better developers. Needless to say this does not just apply to software development, but this domain makes it easier to see the link to the phenomenological thinkers.

20111119_1643_SunsetCropped

Phenomenology

Phenomenology focuses on the process of the ‘coming into being’ or ‘Appearance of a Thing’, rather than just focusing on ‘Thing’ itself. This is a very difficult concept to understand but I believe this focus on the process of how we see or know anything is key to healing the destructive consequences of the Cartesian subject object split that are so prevalent in our current world.

It has been said that you cannot actually teach this particular way of seeing things but must embark on a process of just trying to do so. It does represent a change of worldview when we come to look at our environment. It means that we need to realise and understand that the ‘Appearance’ and the ‘Thing’ are ONE item. This can also be understood in terms of reconciling the function of the brain hemispheres.

One of the insights about hemispheric brain function that has endured is that the right brain deals with the immediacy of lived experience, i.e. the Appearance of a thing, and the left brain deals with re-presenting what is lived in order to know something, i.e. the Thing itself.

In the words of Iain McGilchrist, the author of ‘The Master and His Emissary‘, the left brain deals with ‘Static, Isolated, Fixed, Decontextualised, Denotative issues‘. It deals with closed systems and perfection. The right brain, however, deals with ‘Individual, Changing, Evolving, Interconnected, Living ideas‘. It handles things that are never fully graspable, never perfectly known.

This we can see when we are looking at something completely new that we do not understand, or have the concepts to fit. We have the right brain perceiving it and the left trying to make sense of what we are perceiving. When we get it (or ‘grok’ it as Robert Henlein would say) we have that Aha! experience which means that we have identified the concept that fits the perception. It is only at this point that we can know something about what we are seeing.

3dBoxA Perception Exercise

It is difficult to put over this idea of the unity of the thing and the perceptive process but perhaps I can give you a sense of how our concepts affect what we see.

Next to this text you can see an image of lines that could be a cube. There are 2 ways to see the image as a cube, (a) one where the front face is at the lower right of the image, and (b) one where the front face is at the top left of the image.

So now just play with switching your perception over from state (a) to state (b) and be aware that nothing is changing in the external world. All you are doing is adjusting your conceptual filter that you are applying to the external percept.

Now can you see another way of seeing it? Try looking it to see a third way before reading further…

It should be possible to see it just as a flat image with lines on it. Not easy once you have seen the cube. If you have a laptop then perhaps rotate the display 45 degrees and that will make it easier.

If you spend some time with this you might be getting more awareness of what is happening inside you as you change your concept filters.

I am going to leave it there for now.
In the next post I will spend more time going deeper into the links between software development and phenomenology.

Why Software Development Requires an Evolution of Consciousness

Posted on by

I was recently sent a link to a set of 3 essays by Jack Reeves dating from 1992. He was a proponent of the idea that software was ALL design, even down to the area of testing, comparing it with traditional engineering processes which had a significant focus on the phase of building something. In software development building it is a miniscule part of the process, now frequently done under automatic control, especially if you are using CI (Continuous Integration) systems. This means that the traditional build phase in software is almost a non-operation (called a no-op, or nop, by techies). Click an icon and – bang – its built.

However there was a little nugget in one of Jack’s essays which caused a rather big “Aha!” moment for me. I recently gave a talk at ACCU2013 in April (slides here) which was based on my research into phenomenology and software, words you don’t usually see together, as well as my interest in the struggle between seeing the whole and the parts, as wonderfully researched by Henri Bortoft. Jack Reeves made a point which connected with these ideas of the whole and the parts, monism and dualism, etc. His point is fairly obvious to anyone who has done any significant amount of software development as he identified that the high-level software design influences the detailed low-level design (to be expected), but ALSO that the detailed design will influence (or should be allowed to influence) the high-level design.

To quote Jack:

“The high level structural design is not a complete software design; it is just a structural framework for the detailed design. We have very limited capabilities for rigorously validating a high level design. The detailed design will ultimately influence (or should be allowed to influence) the high level design at least as much as other factors. Refining all the aspects of a design is a process that should be happening throughout the design cycle. If any aspect of the design is frozen out of the refinement process, it is hardly surprising that the final design will be poor or even unworkable.”
http://www.developerdotstar.com/mag/articles/reeves_design.html

I can hear the programmers among my readers saying: “So what?”, but seen from the perspective of how difficult it is to grasp the relationship between the whole and the parts, I now realise that it is this issue that causes such difficulty when writing software systems and why traditional hierarchical methods of management will not work. This should ring significant alarm bells for anyone wishing to manage a software project because due to the inherent complexity of systems it means that the smallest details down in the low-level design can trip up the whole project effort.

This is why I am so sceptical about large system initiatives managed in the traditional way. One of the latest casualties being the BBC DMI initiative which was abandoned after a project spend of £98 million. Ouch.

This does NOT mean that we cannot make large systems, it just means that we must factor in this tight link between the whole and the parts, the high and low level design. This is hard, even requiring a significant evolution of consciousness if we take on the ideas of Henri Bortoft and the Goethean scientific approach.

So much of our culture sits on assumptions that hierarchical structures work. Indeed a top-down approach is the usual way that I have done projects in the past. But I have to jump to the risky items FIRST, many of which will be low-level design problems that, if not solved, will mean the whole effort is a waste of time. This is why I much prefer attacking problems incrementally, which is a much more organic process and also explains the rise of Agile software development techniques.

In the end it means that as a programmer, if I am to be successful, I must be aware of the way I think and how I perceive the world. Maybe this is why I have recently become interested in watercolour painting – but that is another story…

The Importance of being an Amateur

Posted on by

Just recently I have been preparing a talk that I shall be giving at ACCU 2013 in Bristol. Luckily the Bath & Bristol chapter of the ACCU asked me to come and give a dry run of the talk recently and thanks to their many constructive comments I have just finished tweaking and finishing the talk for the main conference.

In preparation for the talk my main texts have been a combination of Henri Bortoft with his “Taking Appearance Seriously”, Iain McGilchrist and his magnum opus “The Master and His Emissary”, and finally- of more import for the techies among us – another magnum opus from Christopher Alexander, his “The Nature of Order” series (which I shall refer to as NoO!).

During the preparation I have been reading these works primarily in “reference” mode, making notes and actually trying to “study” them more. However, now that the main prep is over, I decided to jump forward to the last of the four books from Alexander. So far I had only got to half way through the second one.

Given the slides I had prepared for the talk, some of which included the titles “The Importance of Energy” and “The Foundation in Play”, I was surprised to see just how well they meshed with Alexander’s approach in his Book 4 of the NoO series.

I was particularly struck by his comments about Chartres cathedral and was desperately trying to relate it to software development when a particular thought struck me between the eyes. Although Alexander never mentioned the word, one of the main drivers that the artisans making cathedrals would have used would have been the LOVE of the job, particularly given the religious context so prevalent at that time.

I then reflected upon the background history of software development and realized that it has usually been the polar opposite of this approach, since its main roots are in the military and past war efforts, particularly WW2 and the work at Los Alamos on the atomic bomb. So I then realized that a major reason why I am interested in this more human approach is in order to counteract the lack of humanity that is prevalent in software development, an easy trap to fall into given the focus on technology, and its associated roots in the military.

I then remembered the root within the word amateur – i.e. doing it for the love of it – and realized that this is an important driver for taking the time to make software development truly become a craft and an art. Thus, in order to ‘heal the Cartesian split’, as I mention in the talk, we need to bring more of this feeling of doing it for the love of it, and this is exactly what Christopher Alexander is driving at. He has a great story about getting his students to paint Easter eggs in order for them to learn how to create buildings with good centres or beings as he is also calling them.

I have included the section entitled ‘Innocence’ here as I feel it says a lot about what is needed to truly be an ‘architect’, whether of a building or of software. But unfortunately I am not usually given the time for such exercises and have had to develop this perspective in the background throughout my career. I suspect this is a common experience. But maybe I am just too much of a dreamer…

Extracted from Book 4 of “The Nature of Order : The Luminous Ground” by Christopher Alexander. pp99-100.

12 / INNOCENCE

It may help for me to describe a class I once conducted, in an effort to improve the students’ ability to form buildings from beings. I first asked each student to give an example of an innocent process of drawing or making an ornament which they had most enjoyed. I was looking for something which had been truly joyful for them, not part of their student training. They gave various answers. As I listened, I noticed that the smaller the examples were the more true – that is, the more innocent they were, the less contaminated. Then one student said, in a very soft voice, that he had enjoyed painting Easter eggs in his childhood. That was something that was pure joy, unaffected by guilt, or by a feeling that he must “do well.” At first I could not hear him. He was shy about it, didn’t want to repeat what he said. I persuaded him to speak a little more loudly, and finally we all heard him say, embarrassed, that he had loved painting Easter eggs.

I felt at once that this love, of all those which had been mentioned, was one of the most pure. It was simple. In that work, there is nothing except the egg and the pattern on its surface, no mental constraints of what one “ought” to do – only the thing itself. No one really judges or censors the outcome – so it is easy and alright, not festering with complicated concepts about architecture when you do it.

So I asked each student to make holes in the ends of a raw egg, blow out the yolk and white, and then paint the egg, decorate it like an Easter egg. I made it clear that they did not have to use the fifteen properties. All I wanted them to do was to make the egg beautiful, to enjoy what they were doing. Here are some of the eggs they painted. The shapes and spaces in the ornaments took their shape, and became what they are, just to be beautiful and to have the maker’s depth of feeling visible and shining in them. That was the only principle which governed them. And this, I believe is what one has to do to make a serious work. Naive as it sounds, it is this, too – I believe – that the great traditional builders did.

The students’ other architectural work improved greatly once they understood that making a good building is more like the joyous work of painting an Easter egg than like the practical task of being an “architect.”