Phenomenal Software: The Need for Exact Imagination

This is a crucial aspect of being a software developer – the ability to hold an exact imagination of the processes occurring within a system. Fundamentally whenever we have to debug or design a system we need to try and ‘run’ the system or subsystem within our own thinking, if only in part.

It is one thing to appreciate how the concept of ‘imagination’ can be used to describe this process, but it is another to truly understand the deeper aspects of the faculties we need to develop in order to perform this activity. In my experience most software folk have either developed some of these faculties unconsciously at school and/or university, usually by studying maths, or pick it up as they go along during their career – both frighteningly haphazard processes. We may need to include art training for the technical professions.

The Process of Goethean Science

My view is that the insights of Goethean scientific perception can help here, though there are some important differences due to dealing with dead machines instead of a living natural world.

First lets review current ideas about the steps that are used in Goethean scientific perception (See Wahl and Brook):
Created while on a painting course by Claire Warner.

  • Exact Sense Perception.
  • Exact Sensorial Imagination.
  • Beholding the Phenomenon.
  • Being One with the Object.

Usually these steps relate to the perception of natural phenomena rather than to software where we are dealing with human created entities running within a computer, but they are still relevant.

In computing the stage of Exact Sense Perception relates to either developing requirements (when designing) or observing the behaviour of the system (when debugging). I am not going to deal with this step in this post so that I can concentrate on the imagination stage. I will assume that either we have the requirements for a new piece of software, or we have followed the ideas in my previous post when investigating the behaviour of a faulty system that needs debugging.

In imagining these human created entities, or thought structures, we first need to duplicate them in our thinking. However, there is a state beforehand that is worth mentioning as in the above it has been accepted as a given. This is the step of ‘Developing a Focused Attention’ – which is a foundation for all that follows as I shall describe later.

Another point we need to deal with here is that when we work with these thought structures in our heads we have moved away from the sensible world and are using what Rudolf Steiner called sense-free thinking. Certainly we may aid our imagination by naming the structures after physical items, e.g. a pipeline, but we have also created new ideas, e.g. a FIFO [first in first out pipeline], that are not physically based at all. The entities we are dealing with are not sense-perceptible and are not physical items and so it is not accurate to call it Sensorial – a better name being Exact Sense-Free Imagination.

Thus I see the steps as follows:

  • Developing Focused Attention
  • Exact Sense Perception (not dealt with in this post)
  • Exact Sense-Free Imagination
  • Beholding the Phenomenon
  • Being One with the Object

Developing Focused Attention

K13 Approach
In the past this would not have needed mentioning but given modern issues of reduced attention spans it needs to be brought to awareness. I consider this to be the most important faculty I have developed over the 30 years of my career in a technical domain and it is very relevant to life in general. When a software problem is found by a customer it can result in them being quite vocal and upset and getting angry – an appropriate response if they have paid for the system.

This heated response and emotionality can ripple through the vendor company as the customer interacts with its various levels of sales, support and management. If the emotionality persists all the way to the level of the programmers, it is going to be impossible to cleanly fix the problem and will result in a lot of costly, ineffectual ‘thrashing’. This is because in order to properly imagine the system in their thinking, the programmer must hold a focused and clear attention. In effect they have to push the worries of the day-to-day economic world away while they calmly and quietly identify and then fix the fault, possibly educating the various stakeholders about what they are doing in order to gain a little quiet space and time.

Although the customer may be getting ‘appropriately’ angry, ideally this attitude of calmness needs to be developed by all members of any technologically dependent society. Otherwise we will experience a degradation in the quality of our lives as we persist in holding expectations that are not in touch with reality. We need to become more aware about the implicit issues of technological use as it amplifies our intent, including our mistakes. This is where an aggressively economic stance can adversely affect our lives and thinking.

This stage of focused attention requires that we develop our ‘Will’ in the realm of our thinking. We will not make progress by letting our attention wander and our thoughts flit around like moths near a flame. This use of willpower is one of the reasons that the practice of software development is so draining and I liken this to creating and holding a quiet, almost physical, space in my mind in which to run the system in my thinking. (Those of a more spiritual/religious nature might see this as a sacred space, like that of a church, grail, or sanctuary.)

Exact Sense-Free Imagination

BufferThe current prevailing view is that when we are imagining a system in our thinking we are using a visual metaphor. This idea has been furthered by the move from procedural programming to object-oriented programming back in the 80s [See footnote 1]. This assumption has also been consolidated by the discipline making use of the idea of patterns put forward by Christopher Alexander [See footnote 2]. The architectural patterns for buildings indeed are visual entities, but when it comes to imagining the interactions of software structures it is more complicated. (You might actually say the same about building architecture but that is another discussion.)

There are two main aspects to what we have to imagine, first there are STATIC structures, and secondly there are DYNAMIC operations that occur between these structures.

Imagining the static element is when we build the system, usually only partially, in our thoughts first. Here ‘Thought’ is the noun use of the word, and is as close as we come to a visual representation of the code since we usually create a structure of ‘Thoughts’ out of the data structures or objects (if we are using object-oriented programming).

This means that we are imagining sense-free thought structures in the quiet space we have created with our focused attention.

Next is the harder aspect of imagining the dynamic operation of the system. The computer will perform operations exactly in line with the software we are about to write (design) or that we have already written (debugging). When designing we need to imagine if our proposed structure is going to give the required result for the specification drawn up for the system. When debugging we need to imagine what the system is doing and why it is not performing as we expect given our knowledge of the code.

In both these scenarios, as we think through either reproducing the static structures or the activity of the system we need to incrementally move our imagination forward in steps to be sure it is congruent with the code or proposed coding ideas. This, thanks to the operation of the computer, is why this process must be an ‘Exact’, non-fantasy imagination.

A frequent error here is to ‘run ahead’ of the simulation in our heads, missing out vital steps – so we need to start small and will usually use paper and diagrams to help us along. Interestingly I have found a printing whiteboard to be invaluable as the gross motor movement in drawing a structure diagram in the large helps to improve the visualisations of the thought processes and imaginations (schemata as Johnson says in The Body in the Mind).

However the fact that we perform this imagining of the dynamic system state, along with my own experience of the process (many programmers will ‘see’ the code in their mind’s eye), makes me sceptical that we are dealing with a purely image based and visual domain here. This is a current work-in-progress for me at the moment.

Note how this need to NOT run ahead of the simulation echoes the idea of Delicate Empiricism – which leads us neatly onto the next stage of ‘Beholding the Phenomenon’.

Beholding the Phenomenon

This is where we actively perceive the behaviour of our (hopefully exact) imaginations and necessitates switching constantly between imaginer/creator and perceiver. I find that nowadays I do this without noticing the switching, but it takes a significant amount of energy as this is another activity that requires a lot of willpower.

I am having to use my Will to:

  • Maintain focused attention.
  • Create thought structures.
  • Move my imagination through time as I simulate their interactions.
  • Behold what is happening and compare with the requirements.

The best way I can describe the feeling here is that of using a lot of attention to just hold the structures and keep the dynamics ‘alive’ and wait for the perception to catch up. This is why I consider that the word ‘beholding’ is a good way to describe it because we need to balance letting the imagination ‘live’ along with keeping it ‘Exact’.

There is also a very delicate, sensitive ‘cognitive feeling’ going on here when designing and comparing to the requirements as I assess if I am creating the right structures. I will return to this idea in a later post as it relates to Christopher Alexander’s work.

Hopefully this makes it easier to understand why programmers frequently get that far away look in their eyes. Given the complexity of what is happening is it any wonder that bugs occur in our creations?

Being One with the Object

Although difficult to reconcile with the perception of the wholeness of a natural organism, by thinking of this as a creation of knowledge, understanding and meaning, we can make the link. This is the ‘Aha!’ experience and is just as relevant in computing as in traditional science, Goethean or otherwise.

Gliding Sunset

This is the moment when we bring life to the whole enterprise, using our uniquely human faculties.

In a computing context this means that either we have truly understood the detailed elements of the problem and have identified the structures we will need (design), or we have experienced the blinding clarity of seeing exactly where the problem lies (grokking it) and know what we need to do to fix it (debugging).

Health Warnings

When working with computers we need to realize how it can fossilize our thinking. Because we constrain our inner process to be in step with the machine, we can delude ourselves into thinking that we are just machines. Indeed we may even change our judgement to be far too rule-based, the essence of computer operation.

We need to hold onto the idea of a ‘Living Thinking’ (as Steiner would call it) and I find that the phenomenological ideas of Goethe and those that followed can help us in keeping this uniquely human perspective when dealing with the mechanized world.


Next time I shall go more into the ideas of patterns, Alexander’s ‘apparent liking’ and ‘true liking’, and the idea of how we use a very fine ‘cognitive feeling’ to judge the rightness of a design.

[1] This was a major change in the way humans thought about programming computers. Initial techniques involved stringing together sequences of machine instructions into procedures that manipulated data, hence the term procedural programming. However it was then decided that it would be a better to give the data structures primacy and attach the procedures to the data. Thus software development became based upon designing structures of objects (or more accurately: instantiations of abstract data types) i.e. data structures with ‘attached’ procedures. Thus was born the idea that you could visually represent software structures which would make it all much easier to imagine.
[2] Christopher Alexander is a mathematician turned architect. The software discipline has used this idea to provide design patterns for software structures. His magnum opus is the 4 book sequence called ‘The Nature of Order‘.

6 thoughts on “Phenomenal Software: The Need for Exact Imagination

  1. in order to properly imagine the system in their thinking, the programmer must hold a focused and clear attention

    Nothing could have brought this home to me more vividly than the effect of depression over recent weeks: I found myself unable to concentrate and as a result was unable to work during that time. A clear mind is of paramount importance.

    Thinking about imagination: Edward Casey described two “factors” of imagination, spontaneous and controlled, with controlled being the type of imagination you describe here. He described it as a wilful effort to manipulate images in the mind. My own imagination is heavily oriented towards this factor which I believe helps in the context of visualising static and dynamic systems. It comes naturally and is almost effortless.

    I find it interesting that you refer to “a very delicate, sensitive ‘cognitive feeling’” because I feel an almost intuitive sense of when something is right. I guess this is something that derives from experience.

    • Hi Ben,
      Yes, because it depends so much upon our internal state, I can have some days which are easily 10x more productive than others.

      I suppose I was also trying to get to this nuance in imagination with the ‘beholding the phenomenon’ section where there are the 2 types as you say, the controlled ‘Exact’ type and the letting it ‘live’ which I would equate to the spontaneous type. I have been reading Mark Johnson’s book (The Body in the Mind) where he cites Kant’s breakdown of imagination into 4 types, but am still processing that at the moment so will be hoping to integrate this with Steiner’s ideas of imagination, inspiration and intuition. But that will take some time…

      You are exactly right in your comments about the ‘cognitive feeling’. This is something I can almost tangibly feel and sometimes when a younger programmer suggests something that I just know feels wrong, I tend to let them try it unless I can fully express why it is a bad idea. Then only when I find the concrete reason will I have the knowledge explicit for the future. And of course there is always the chance I am wrong! But generally I think our experience ‘trains’ us into developing a sense of the rightness or otherwise of an idea.

      All the best

    • Hi Simon,
      Thanks for the comments about the article. Now to your question.

      This is a pretty big subject but there are some basic ideas that might help here. The Google implementation is based on the MapReduce structuring run within a scheduling system that gracefully handles failures in the processor clusters. Last I heard, they do not replace a rack of processors until a certain percentage of them are failing as it is not economically feasible to do so, and then they will replace a whole rack, therefore they need scheduling that can handle failures in the clusters.

      MapReduce is a pretty simple processing graph idea and can be written in a few lines of Python though of course the actual processes that are run in the graph are where the extra complexity lives. Scheduling is inherently rule-driven and something our computers are doing all the time, though of course at Google and the like, the number of the jobs they are running in parallel is much much higher.

      We need to remember that computers are primarily calculators and are programmed in terms of lots of parts. A computer’s operation is purely a sum of parts – in Henri’s terms there is no wholeness – and each of these parts represents a finalized (and non-living) thought construct produced by a human being. So as mentioned in a previous post a computer is running a network of these thought constructs.

      I can see that there are many people today who think that if we make a suitably complex network of thought constructs and throw a suitably complex set of data at it we will get an ‘emergently’ living thing. I do not agree. Complex it is, yes, but it is still a combinatorial operation of pushing many inputs through a network of fixed structures. Even if those structures have themselves been ‘genetically’ modified by the machine in response to previous inputs.

      To me this is still not a living thing as it lacks the Goethean ‘wholeness’. The phenomenological hermeneutic ideas about how humans continually construct meaning give it the lie here. I consider that a computer, i.e. a fixed set of processing constructs that are completely rule-driven, will never construct new meaning.

      Humans can act in a rule-driven way, and when we do so we are acting like a computer. This happens when we are fitting existing structures (mental pictures) onto phenomena. This is NOT the same as when we are building new knowledge and do not have the pictures. But the fixed structures (pictures) are ALL the computer has, both in terms of data AND programming, that is its nature. It is the human being who has engaged in thinkING to produce fixed thought structures that are then programmed into a computer and used as rules to control its operation. Running a network of thought structures is NOT thinking, no matter how complex the network.

      So, in the article, I think the chief of Cumulus Networks, one JR Rivers, was correct when he used the term ‘the law of unintended consequences’. This is actually what we humans are learning about in building these big computing projects. We are not making living things.

      [Hmmm. This looks like it will warrant a future post. Thanks for the question and apologies for the long answer. It is not a simple issue and I have only lightly touched on it.]


      • Hi Charles, many thanks for your considered reply. As you said, there is a lot of food for thought and we always need to be clear as to what we mean by the term “living”.

      • Hi Simon, Yes indeed and that is something I did not really deal with in the reply. I think the short answer is in the relationship between the whole and the parts and the presencing/becoming, but those are all loaded words and I think I want to work on this a bit more and make a separate post since this relates to my conclusion of the original talk. I find Steiner’s ideas helpful though in trying to get to understand livingness.

Comments welcome. Let me know what you think...

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s