If all you have is an Elephant and 6 Blind Men

I was in a presentation the other day where (once again) a speaker invoked the Blind Men and the Elephant parable to explain some misunderstanding

I'm sure you know the one:

• There's a large IT project with a lot of different people involved.
• There are differences of opinion about what is important
• According to the speaker, the reason we can't agree is because everybody is concentrating solely on their portion of the system rather than looking at the system as a whole.

I can't remember how many times I've heard this story used and I'm sure you've also heard it plenty of times. In fact, as architects in the IT world it seems to be one of those Metaphors We Live By.

Unfortunately it also seems to be the only analogy we use to explain this situation. As such it is a good example of another analogy that is used (and abused) in our discipline - If all you have is a hammer, everything looks like a nail.

Here's an alternative so we can have more than a single hammer to explain different perspectives on large projects:

Fly, Bat, Worm.

This was described in Neal Stephenson's book Anathem and it goes something like this. Instead of 6 blind men groping different parts of the elephant, imagine a Fly, a Bat, and a Worm perceiving the entire elephant and trying to communicate with each other about it. The (ideal) Fly perceives everything solely through sight, the (ideal) Bat perceives everything solely through hearing, and the ideal Worm solely through touch. How can these three discuss what they have perceived? How does a deaf Fly describe something to the blind Worm, or vice versa?

"[The Fly] says 'the worm seems to be relating some kind of account of its wormy doings, but since I don't squirm on the ground and can't imagine what it would be like to be blind, I haven't the faintest idea what it's trying to tell me!'"

While different people working on a large IT project don't perceive with different senses, they do conceive their mental models of the proposed solution differently. We're not so starkly different as to be communicating like a blind Worm to a deaf Fly, but the people working on a large project have different types of knowledge through which they both understand the problem domain and devise solutions using IT. Even people with nominally similar roles can have quite different detailed knowledge models of their area.

For example, Enterprise/Solution Architects are not completely divorced from the "wormy doings" of the Operations people who "squirm on ground"[*], but they are culturally different. Even if you have experience across all the different facets of Business and IT, different levels of expertise result in different levels of detail in the conceptual models we use to understand our problems and solutions. We might use the same terms in discussions but that does not mean we are immune to cultural differences in understanding. In fact the way we use the same terms often hides the differences in understanding that we have. We may think we have reached consensus, but internally we can have quite different interpretations of those words - i.e., the contexts that govern their meaning - and therefore the consequences for how they interact to provide a solution. "Service" anyone?
[*] No offense to the excellent Ops people I know. s/Operations/Development | TechArchitect | BusinessArch/ etc as required.

Designing a system requires constructing an understanding - a conceptual model of the solution. I.e., the concepts, relationships and interactions that need to exist for the solution to work as intended. It is a constantly evolving process that combines models of the problem domain with possibilities presented by the technology in our solution domain. We need to iterate on this process to improve our knowledge of both during design. And on large projects we also need to collaborate and reach consensus with others while performing this iterative learning process.

But how we understand the problem domain and how we devise solutions within it is subjective, not objective. How we identify concepts in the domain is theory-laden. How we devise explanatory models is influenced by our culture, language, and expertise. The definition of culture when we consider its influence on developing models can be as broad as "western culture" or as narrow as "java developers", "declarative language developers", "scrum practitioners", "enterprise architects", "EAI integration expert", "enterprise architect", "DevOps", etc.

We don't perceive the same reality and simply create different models for it. We understand that reality through our existing sets of concepts. To bastardize another metaphor. We see our domains, and solutions, through culture-tinted glasses. Whether we are explicitly aware of this bias or not.

I'm not going deep into the theory in this post, but the fields of metaphysics, epistemology, cognitive psychology, neurophilosophy, philosophy of science, philosophy of social science (and others) all deal with this issue in their respective fields. And while there are many debates in those fields about the extent to which subjectivity influences how we gain, use, and communicate knowledge, its certainly broadly agreed that it does influence it. If you're interested, here's a popular recent article in the NY Times on the role of language and how it shapes how we conceive reality.

The influence of subjectivity in system development is not new in IT. Some researchers and practitioners have been discussing its effects since the 60s. People such as Peter Naur, Terry Winograd, Meir M Lehman, and Bruce Blum. The most interesting aspect is that it is now slowing filtering through to the mainstream IT world's books and conferences. E.g., Domain Driven Design alluding to the influences of modelling and Kevlin Henney's JAOO presentation on the role of Metaphor (pdf) just to name two.

But we should be considering it more explicitly. As Gotleb Frege wrote,

The objects in the world are already delineated to some extent by the classifications embodied in socially inherited language. In fact, learning a language essentially means learning to grasp objective thought concepts.

We should be spending more effort understanding how this influences large-scale system design and development.

Which brings me back around to the situation that usually results in the Elephant and Blind Men analogy being deployed:

• There's a large IT project with a lot of different people involved
• There are differences of opinion about what is important
• The reason they can't agree is because it is impossible for everyone to see the same holistic picture. Not because we are concentrating solely on individual portions of the system rather than looking at the system as a whole.

We observe and use the same terms to talk about the overall design but we conceive it differently based on our cognitive apparatus. We're not all looking at different parts of the same elephant. On a large IT project we can all see the whole elephant, we just see it differently - like looking at an Andy Warhol picture of an elephant.

The only way to overcome these differences is through interaction and feedback. Not to say, "but you aren't looking at the big picture", but rather, "what do you mean by that?", and "can you give me a specific scenario?".

---

Image references:

Blind Men and the Elephant: WikiMedia Commons
Warhol Elephants

Read more

SEMAT and the origins of Software Engineering

I hope commentators on the SEMAT initiative - on both sides - have read enough history so that the rest of us aren't doomed to listen to a repeat performance of the last 40 years.

Its been interesting for me to follow the initial steps of the Software Engineering Method and Theory (SEMAT) initiative. Reading the SEMAT blog and articles revived memories from when I spent a bunch of years doing research on software engineering foundations. So I'm very curious to see how it progresses. Unfortunately, the initial buzz reminds me a lot of the fledgling steps of the original "software engineering" movement and I hope we don't waste an opportunity to deal with an important issue by continuing to bitch about the meaning of the word engineering.

Its hard to argue with the SEMAT Call to Action - especially the identification of immature practices. We do lack a theoretical foundation that provides both an explanation for the practices that have proven to be useful and a justification for proposing approaches for further improvement. (unless of course you believe we have already reached the pinnacle for software development effectiveness)

Many of the responses to the initial Vision and first workshop (google blog search semat,  twitter search #semat) are made by knowledgeable and insightful commentators. However, a great deal of what I read is simply a restatement of arguements that have been made in our discipline - that were often made more eloquently and constructively - for more than 40 years. Perhaps catching up with a bit of history can focus people on providing an improvement rather than rehashing old opinions.

---

P. Naur and B. Randell, (Eds.). Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969) 231pp.	B. Randell and J.N. Buxton, (Eds.). Software Engineering Techniques: Report of a conference sponsored by the NATO Science Committee, Rome, Italy, 27-31 Oct. 1969, Brussels, Scientific Affairs Division, NATO (1970) 164pp.
The transcripts of the original two software engineering conferences are available online. They contain many working papers,  but most importantly, also transcribed debates between the participants which capture very interesting views on both sides. As a bonus, there is also the first analogies I can find between software design and the design theories of Christopher Alexander

---

The NATO conferences on software engineering were held in 1968 and 1969 and were intended to provoke ideas for improving software development. Indeed the term "software engineering" was meant to provoke and not to dictate a frame of mind needed to produce dependable software.

The phrase ‘software engineering’ was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering (1968, Preface)

There were many debates about the nature of engineering and whether or not it can be applied in software development which elicited useful insights into the nature of software development. Indeed, some of those comments allude to understandings which are considered relatively recent, such as agile development.

“[Naur] In my terms design consists of:
Flowchart until you think you understand the problem.
Write code until you realise that you don’t.
Go back and re-do the flowchart.
Write some more code and iterate to what you feel is the correct solution.” (1968 Report)

Additionally, there were points made, such as the usefulness of mathematical formalisms for software development, which are still not satisfactorily addressed today.

The important take away is that the result of the first software engineering conference was debate. The term engineering was put forward to provoke discussion on a commonly agreed set of problems - a Call to Action.

The problem was when they reconvened in 1969 for the next conference. The thing you notice in the transcripts is that the topic of debate has changed. There is no longer a sense of how should we frame our thinking to resolve these issues. The notion that software development could be "engineered" had taken hold. The only question now was, how. This was also explicitly pointed out by the editors of the transcripts:

Unlike the first conference, at which it was fully accepted that the term software engineering expressed a need rather than a reality, in Rome there was already a slight tendency to talk as if the subject already existed. And it became clear during the conference that the organizers had a hidden agenda, namely that of persuading NATO to fund the setting up of an International Software Engineering Institute. However things did not go according to their plan. The discussion sessions which were meant to provide evidence of strong and extensive support for this proposal were instead marked by considerable scepticism, and led one of the participants, Tom Simpson of IBM, to write a splendid short satire on "Masterpiece Engineering" (Editor's report)

(btw: anyone who thinks they have a witty and insightful take on why software development isn't like engineering should read "Masterpiece Engineering")

This communication gap in the 2nd software engineering conference happened very quickly and was not overcome. This resulted in a whole group of people who could have made useful contributions being removed from the debate.

The sense of urgency in the face of common problems was not so apparent as at Garmisch [1968]. Instead, a lack of communication between different sections of the participants became, in the editors’ opinions at least, a dominant feature.” (Editor's report)

Its pretty clear in the external commentary of the first SEMAT workshop that this is happening again. Whether or not they have chosen to remove themselves from the effort, there is now a significant group of people who could be helping to achieve the goals of the Call to Action who are simply not taking part.

There is always risk that the subject of debate gets 'highjacked' by a particular side - such as those who believe that software development can be engineered. Using the word "highjacked" is very emotive and implies a deliberate misdirection of a movement, but in reality it is that people are at risk of pushing an approach that simply conforms to their preconceived world-view. Many of the comments on SEMAT and software engineering in general appear obvious to their authors and their like-minded colleagues. But they make little sense to the people on the other side. They are based on incommensurable viewpoints. That is, you simply can't find common basis for comparing them.

We each have a worldview through which we understand our domain (in this case software development). Those worldviews can be incommensurable like the pro- and anti- software engineering camps. But there is no right or wrong answer answer here. The only thing that matters is whether or they provide useful suggestions for improving our discipline.

I don't know if engineering is the most useful paradigm through which software development can be improved. However, you only have to have a basic understanding of philosophy of science to understand that its not possible to tell until after theories have been developed, evaluated, and falsified.

The SEMAT Call to Action captures issues that exist in software development. The software-engineering group needs to devise theories which can be proven useful in resolving those issues. The its-not-engineering proponents should be doing the same. It will help everyone if the debate between them continues instead of becoming a divide that stifles possibilities.

I'll finish off with my favourite quote by Dijkstra and Randell in the '69 transcripts:

“Dijkstra: I would like to comment on the distinction that has been made between practical and theoretical people. I must stress that I feel this distinction to be obsolete, worn out, and fruitless. It is no good, if you want to do anything reasonable, to think you can work with such simple notions. Its inadequacy, amongst other things, is shown by the fact that I absolutely refuse to regard myself as either impractical or not theoretical.
...
What is actually happening, I am afraid, is that we all tell each other and ourselves that software engineering techniques should be improved considerably, because there is a crisis. But there are a few boundary conditions which apparently have to be satisfied. I will list them for you:
We may not change our thinking habits.
We may not change our programming tools.
We may not change our hardware.
We may not change our tasks.
We may not change the organisational set-up in which the work has to be done.
Now under these five immutable boundary conditions, we have to try to improve matters. This is utterly ridiculous. Thank you. (Applause).

Randell: ... ‘There’s none so blind as them that won’t see.’ ... If you have people who are completely stuck in their own ways, whether these are ways of running large projects without regard for possible new techniques, or whether these are ways of concentrating all research into areas of ever smaller relevance or importance, almost no technique that I know of is going to get these two types of people to communicate. ... You have to have good will. You have to have means for people to find out that what the others talk is occasionally sense. This conference may occasionally have done a little bit of that. I wish it had done a lot more. It has indicated what a terrible gulf we so stupidly have made for ourselves.

Read more

improving software architecture competence

How do you go about getting better as a software architect?
You'd think there would be plenty of information available.

Recently our local IASA chapter had a session on Improving Software Architecture Competence, so I threw together some thoughts to present.

I figured it would be pretty easy. There must be lots of documented experience of what individuals or organisations have done to improve themselves, right? Well, there doesn't seem to be. There is plenty of information about sw architecture course syllabuses (e.g., IASA's own education program) and no shortage of opinion about what software architects should do/read, but almost no experience reports saying, “this is what we tried and this is what we learned about trying to improve our software architecture competence”. (BTW, there may be some out there – I don't claim to have done any more exhaustive research than some simple googling).

However, I did dig up two interesting articles to summarise, and I think they are useful reading for someone interested in the topic. The first questions the ability for any sw architect to learn and improve using the kind of education techniques we currently have. The second – a workshop on improving software architecture competence – is the sole experience report I could find.

•  “On System Design”, was an Essay delivered at OOPSLA a few years ago by Jim Waldo. In it, Waldo laments what he sees as a decline in the art and craft of system design. He points out a number of reasons for this, but the the most relevant here is his observation that we are unable to adequately train people in system design the prescriptive techniques we currently use. Indeed when considering the qualities of good designers, how they think and work may be more important than what courses they have done.

• An experience report summarising the result of a workshop on improving software architecture competence that was hosted by the SEI. The report summarises 5 experience reports from organisations, plus an acedemic perspective, who have a competence improvement program in place. There also exists a related presentation and podcast that summarises a survey the SEI did of the architecture community that led to their own software architecture competence program and framework.

Both are useful reads if you are interested in the topic and there are plenty of notes in the presentation. If you've seen another resource on this topic I'd appreciate it if you provide a pointer in the comments.

"...good design is a capability that some people have, and others simply do not...
Whether this is an innate skill that people are born with, or one that is cultivated over time in ways that we don’t understand, is a question far too deep for me to address here. I neither know nor care...
But by the time someone is designing a computer system, whatever it takes to be a good designer is either there or it is not. When it is there, it can be developed and honed. It can also be degraded or warped. But when it is not there, there is no technique or process that can make up the deficit..."

"Everyone I talked to had a similar story of the master designer who had, either consciously or by example and correction taught him or her what they considered to be the important lessons in design
... Design, if my experience is any indication, is best learned by a long and varied process of trying, failing, and trying again under the guidance of someone who is an expert at the task". Waldo, On System Design

On a related note. I'm looking forward to Fred Brooks' upcoming book, The Design of Design: Essays from a Computer Scientist

Read more

new blog

Its seems to be quite popular for Sun people to be shifting blog address and I'm doing the same.



Now that OpenESB has been made "non-strategic" and while we wait for the legal processes that take place during the acquisition of global companies, I've got some more time to spend working on software architecture in general. So I've started up an another blog where I can keep track of my ideas.
I have no idea if anyone regularly follows this blog, but if you are interested in another viewpoint on software architecture ideas then feel free to come on by.



If I end up with a job at Oracle, and one that provides something worth writing about, then I'll resuscitate the old site.

Read more