me.andering – Willem van den Ende

I’m in Singapore to do assessments . Going out there and seeing for our selves (me and a representative from the customer) makes a big difference in how the assessment works. We could have sent the teams here our ‘standard’ questionnaire, and possibly follow up with conference calls. Seeing the work environment, and meeting face to face allows us to hear the things that are not being said.

Being face to face, sharing meals helps us to establish a working relationship, and get a better understanding of what they are trying to achieve.
If we wouldn’t have gone out to see for ourselves, we would have missed important information, as well as be more susceptible to rumours. “Going out”, the questionnaire still is a useful tool, and the visit delivers richer information. Visiting also disambiguates the questions.

* – the title of this post refers to one of the Toyota Way principles, aka Genchi Genbutsu

** – I went out to see Singapore for myself. Apparently, my self alone, as I left my camera at home.

The unprepared session at agile open prepared us well for the brown bag session Bernard Notarianni hosted subsequently over lunch, to show how they are done in his workplace. These brown bag sessions each deal with a chapter from Quality Software Management (the four volume book series by Gerald Weinberg).

Bernard Notarianni explains the first chapter of Quality Software Management

I’ve participated in many discussions on software quality. Usually, it leads to babble and nothingness… This time was different. Discussion on ‘what is software quality’ was focused, and I learnt a thing or two about it. The format of the meeting is simple. Everyone reads a chapter, there is some discussion on the content, and then the group does one or more exercises – QSM has exercises at the end of each chapter.
They have these meetings every two weeks. At this rate, they’ll be spending the next couple of years working on it. Bernard says it works great for them, and they’ve been doing it for quite a while now – looks like years of fun and learning to look forward to.

Marc calls Bullshit on (perspectives on) SOA (service oriented architecture).

“in the end, it’s about delivering value to the customer, isn’t it?”

I’m having problems with the “Architecture” metaphor applied to software for exactly this reason – software architecture often detracts from delivering value to the customer.

I think it would be wise for those discussing “software architecture” to take a deeper look at architecture than the unthinking stereotype that results from “just using the metaphor”, thereby transforming the metaphor to a (perhaps useful) analogy. Writing this post is my attempt to deepen my own understanding a bit, maybe it will do the same for you
So far, the use of “architecture” seems like a vain attempt of a young profession to borrow credibility from a much older profession. I believe it is time software development learns to stand on its own two feet.
The one thing I’m missing most in discussions and descriptions of “software architecture” is context and history. Building architecture has many “schools”. Each school puts emphasis on other values. An architect, or a team of architects can belong to one or more schools, at the same time, or over time. Or they develop their own style.

Building projects and architects are driven by many factors. For some it seems to be mainly aesthetics:

the piramide @ the Louvre

For others it may be research into new materials:

Eiffel Tower
For others it may be adapting to traditional buildings in the environment:

Shanghai
For some projects (e.g. hanging a photo on the wall) using an architect would be somewhat of an overkill. Using an interior designer might be a good idea in some cases, in the Netherlands they are called “binnenhuis architecten”, meaning “inside (house) architects”. For other projects, an architect is not enough, and an urban planner may be needed:

Scheveningen, the beach front of the Hague

Delft city centre and some of its edges
Other architects, in the vein of Christopher Alexander and Frank Lloyd Wright take a fractal view of architecture. They pay as much attention to why what lamp is hanging where (interior) as to how buildings fit in the (urban) landscape around it:

Monona Terrace Community and Convention Center parking lot overlooking Lake Monona in Madison, Wisconsin, designed by Frank Lloyd Wright

Inside of the convention center, also designed by Frank Lloyd Wright

I used to like the “architect also implements” pattern. Johanna Rothman’s Architects Must Write Code seems to be a more prescriptive variant of the pattern – I’m missing the contexts in which it applies, and contexts in which it doesn’t. Reading Architect as Consultant? it seems Johanna believes architects who don’t program on “the project” can’t work. In Rotterdam we used to say “Kan niet bestaat niet” (‘Can not ‘ exists not). Rotterdam was re-built from scratch, after the city-centre and more was destroyed in a blazing fire, resulting from a bombing in the second worldwar.

If you’re building just a house, “architect also implements” might be feasible, or maybe it is the master builder that also designs. If you’re re-building a city, having the urban planner run around with a hammer and a box of nails would be seen as micro-managemement.

To me the main question is: how does the “architect” know the influence she has on the project, and how does she receive and learn from the feedback about the thing as it is (being) built? For a small project, actually participating in the implementation may be a good idea. I like to pair program with others, and collaboratively develop the (technical) architecture. For a larger project, being present at stand-ups, temperature readings and retrospectives may be a good idea.

We shouldn’t forget that building software is not only about technology. A good “architect” also takes into account the landscape around the software and the people living in it. Diving deep into software development may make one focus on the hammer and nails, and forget about the landscape.

I’m currently involved in an architectural project for a Really Large Corporation that is more comparable in scale to “urban planning”. The role of me and my colleagues is more that of city planners, determining which buildings fit where, and where buildings have to be demolished to make place for highways (I’m consulting on fits and misfits of existing software, software under construction, and assessing the way(s) in which they are constructed and hosted by vendors, internal suppliers and customers).

Actually implementing things, and having done that in the past gives me a perspective that makes it easier to call “Bullshit” on this project. For instance, when SOA related performance issues come up, I can use my experience on implementing a similar system to provide a perspective.
“Implementing” for this particular project wouldn’t make sense to me; I would lose the perspective I need to participate in “urban planning” of multiple (software and organisational) systems.

To me, developing software is about providing value to the customer now and in the future. I prefer to think of “software architecture” as a fractal, taking into acount which types of events have to happen here, placing a lamp if appropriate, and at other times looking at how the buildings fit in the landscape; if and how “architecture” and “architects” provide value depends heavily on the context.