Another very interesting paper on the neuroscience of insight has appeared. In Deconstructing Insight: EEG Correlates of Insightful Problem Solving Simone Sandkühler and Joydeep Bhattacharya monitor various brain areas with an EEG while giving subjects the usual kind of cognitive flexibility tests. They amplify the number of insight events by giving the subjects time limits and hints, and look at the EEG outputs when the subjects report insights and correct solutions.
They see the same two modes - relaxed and focussed - with insights occurring when the EEG shows states associated with relaxation:
Interestingly, we found for timeout trials that would lead to a correct solution after hint presentation, a strong alpha ERS. Increase in alpha activity is usually associated with a relaxed, less active brain, because alpha power was largest in states with eyes closed, i.e. states without focused attention.
There are two ways that this paper is an interesting addition to the work I quote on the Neuroscience page. Firstly, this paper talks about “insight”, while the others refer to “cognitive flexibility”. But the tests are the same, the faculties measured are the same. It’s a bit like speaking of breakpoints at different software layers. The call to draw a widget uses calls to draw primitives like lines and rectangles. So by citing this paper we can get to the neural correlates of insight - a term that I’m more comfortable with than cognitive flexibility, because to get good at this stuff we have to see the causes and effects right through the stack from neurotransmitters to effects on social customs.
The second thing is that it discusses various brain areas other than the prefrontal cortex. Clearly the mode shifting between focussed and juxtapositional involves the co-ordinated transition of multiple subsystems. Here’s a lovely example of such a thing - the Gibbs Aquada:
How cool is that?
Now you might say, “This is all very interesting. If I ever need a fundamental conceptual advance to maintain the backoffice system I am cursed with I’ll remember it!”
But in fact insight is not just in play in famous examples like Einstein imagining himself riding on a lightbeam, Newton’s fruit perturbed brain cells or Archimedes famous streak. To demonstrate this, consider a screenful of code. What does it do? It’s a crazy question, because a screenful of code could do many, many things. Well, unless it’s Java or calling Win32. The fanout of possible behaviours for a program as we add syntactically correct lines is much fatter than the fanout of possible chess game states as we add moves. (It doesn’t matter that most of those behaviours are not interesting - they still fatten the state space.)
Writing a program is in essence a synthetic act, where insight suggests that a certain class or data structure can represent the problem domain and make the desired operations possible. This cannot be done by random guessing or exhaustive search. The upper bound on the effectiveness of our programming activities is how readily we can be insightful. The lower bound is fixed by how well we do all the other things that distinguish grown up professionals from script kiddies, but those other things can easily provide busy work to allow us to forget when we lose sight of how to address the upper bound.
This idea of a search space which becomes unmanageable when insight is lost can explain a persistent and specific abuse of design patterns. I once had the interesting experience of being a lab rat for a disciple of Christopher Alexander, the architect who invented the idea. I was renting an old house that had recently been refurbished - in places rebuilt. It was minimal, even more so than is customary for traditional Spanish fincas. Yet it was a warm minimalism, with niches for lights that naturally threw diffuse pools where one wanted them. I kept getting flashes of the rich vegetation on the shady side of the building, along sight lines that extended all the way across the space. It had the quality without a name, and when I eventually met the landlord who had planned the rebuild, I rather diffidently mentioned software engineering and the connection with Alexander.
He roared with laughter and said, “Christopher Alexander is the reason why I do not have a large architectural practice!” He went on to explain that when he’d first moved to the area he’d built a hut and lived on the beach, as recommended by Alexander. For three years he rebuilt his hut, until he understood why the features of the traditional architecture were as they were. “Then I was ready to build in this place!”.
He’d done very well for himself, having built the houses for all the local dignitaries including the serving Spanish Foreign Minister, but his approach took the investment of his high quality time. He didn’t have anything for architectural grunt workers to do, although he ended up employing his own team of builders, because he couldn’t communicate the importance of quality in the small to contractors.
When I mentioned Alexander the landlord was happy, because he’d felt embarrassed about spying on me in order to see how I used the space. He said that he’d already noticed I’d stretched a washing line between two trees, and wondered why I’d put it there. I explained that I’d dumped the wet washing inside the kitchen door on a clean surface and then hung it in the sunshine, and the following day the construction crew turned up to install a pair of solid mountings for the line! This went on for several months. Fortunately I had read Report On Probability A at a suitably impressionable age. While the architect was watching me, I was watching the architect…
What your Shao Lin Ninja Alexandrian actually does, practicing in the original field of application, illustrates the approach that is necessary for success. Yes, there are design patterns. They are “out there”, waiting to be discovered, and some of them recur frequently. But the discovery takes years of work, finding the vocabulary of the most common patterns latent in spaces, and even then and even for an expert, further exploration and iteration is needed in each case. The conscious involvement of a devotee is necessary. This doesn’t necessarily invalidate Alexander’s early ambition of democratizing architecture (remember 4GLs?), but it does mean that the worker needs familiarity with the idea of patterns, and the cognitive state necessary for spontaneously recognizing the patterns that best simplify, chunk, make a theory of, or compress the problem domain. However egalitarian the toolkit, there is an essential act of becoming explicitly conscious of what is needed, which must be performed somewhere, in some terms, by someone.
If that cognitive state is lost, the toolkit or pattern language begins to perform a different job. Instead of a bunch of sensitivity building suggestions in a sea of subtlety, they become a massively reduced search space. The Gang of Four become a firm of stone engravers, and we get a kind of system integration:
I believe that both paths are entangled in Alexander’s 1996 OOPSLA talk, The Origins of Pattern Theory the Future of the Theory, And The Generation of a Living World. For example, at one point he says:
So there began developing, in my mind, a view of structure which, at the same time that it is objective and is about the behavior of material systems in the world, is somehow at the same time coming home more and more and more, all the time, into the person. The life that is actually in the thing is correlated in some peculiar fashion with the condition of wholeness in ourselves when we are in the presence of that thing. The comparable view, in software design, would tell you that a program which is objectively profound (elegant, efficient, effective and good as a program) would be the one which generates the most profound feeling of wholeness in an observer who looks at the code.
I am without reservation quite happy with that. It remains true even if I extend the context of the statement to include every practical observation or speculation I’ve encountered as I’ve asked why there is structure to be perceived, how we perceive it, why we sometimes can’t perceive it - and even what the ancients (who spent much less of their time in focussed attention) had to say about these things.
Yet later in the same talk Alexander says:
Now we come to the crunch. Once we have the view of wholeness and centers, linked by the fifteen deep properties, we have a general view of the type of whole which must occur as the end product of any successful design process. And because we have a view of it as a whole, we are now able to understand what kinds of overall process can generate good structure, and which cannot. This is the most significant aspect of The Nature Of Order, and of the new results I am presenting to you in this Part B.
It means that we can characterize not merely the structure of things which are well-designed, but we can characterize the path that is capable of leading to a good structure. In effect, we can specify the difference between a good path and a bad path, or between a good process and a bad process.
In terms of software, what this means is that it is possible, in principle, to say what kind of step-by-step process can produce good code, and which ones cannot. Or, more dramatically stated, we can, in principle, specify a type of process which will always generate good code.
This sounds to me like a Software Factory. An organization of what the Consciousness Studies people call zombies - “a hypothetical being that is indistinguishable from a normal human being except that it lacks conscious experience, qualia, sentience, or sapience”. The zombies provide hardware to run an Artificial Intelligence, which is stored in at most a few MBs of paper manuals. The AI is a remarkable achievement, since it requires seconds to hours to perform a single fetch or store operation using it’s shuffling hardware, yet it can miraculously transform ambiguous requirements documents into robust systems elegantly and without error. All hail the process!
I believe the Software Factory is a revealing nonsense. The comparison with the AIs we’ve not yet built using GHz processors and petabytes of store exposes the truth. The only reason anyone ever spent all those work decades on it is that sitting in the meeting rooms, listening to the endless drone of corporate doublespeak provides an excellent source of low level background stress. To get a sense of it, glaze your eyes with Obtaining the Benefits of Predictable Assembly from Certifiable Components (PACC), an offering from the Software Engineering Institute. That’s alright then - problems solved, who’s for a beer! And when they wake up a bit for the conclusion, the celebration of process fits with the stress addicted tendency to “default to heuristics”. We’re all “a tiny, tiny piece of it all”, so no-one needs to exercise the personal awareness that Alexander starts by recognizing as essential.
The idea that our thinking about pattern languages has been trying to pull in two opposing directions, trying to be useful both to people with and without access to their juxtapositional faculty at the time, leads to the question of what would happen if we tried to do one job well. Those without juxtapositional awareness at the time aren’t going to be able to make the inductive jump to insightful solutions however they are tooled up. So what if we abandon that objective and ask how we might make pattern languages more useful as cognitive aids for those who are juxtapositionally aware. Such developments would quickly seem pointless or incomprehensible to those without juxtapositional awareness.
Could that be something to do with the growing interest in functional programming? All of the form with none of the mechanizable boilerplate, and disconnected from the busy-work that addresses the usual problems caused by the boilerplate? Perhaps the net has enabled a critical mass of people interested in having such a conversation to connect, as it has already enabled groups to leverage shared, rich models instead of managerial and process overhead in open source development. If we remove the objective which contains an internal contradiction, might we find that Scheme has been our pattern language all along?