Wrong on many levels, Jeff. Oh, it’s a neat soundbyte, and if you don’t know tango and are feeling enthusiastic but anxious about agile it might give you a bit of a buzz. But saying tango is “not about the steps” is like saying music “is not about the notes”.

Imagine, if you will, a conversation with an experienced, maybe professional tango artist. They’ll talk about passion, sure, but also of the hours spent practising, with or without a partner; the months of frustration when a routine they’d been working on just didn’t come together; the fierce discipline of their last coach; the sore feet and aching legs. You really don’t want to watch an inexperienced tango artist, however passionate.

I’m reminded of an interview with a former Olympic gymnast. She’d stopped telling people about what she did, because of the standard reaction - “oh yes, my son/daughter (mostly daughter) does that”. Invariably the child would be in a school or local gym club, maybe on Saturday mornings: what exasperated the gymnast was the assumption that on the basis of that tiny exposure people assumed both a bond with the more experienced and a right to talk as if they knew what gymnastics really is - hours of training and coaching, long coach journeys to distant schools and sports centres to compete, the missed school and social life, seeing more of your trainer than your parents and friends.

You earn passion by virtue of technique, and you acquire technique through a fervid combination of desire, discipline and dogged will-power. Add a generous helping of experience (and how about a sprinkle of the humility that comes with real experience) and then - only then - can you start saying “it’s not about the steps”.

Though I have concerns with the software craftsmanship movement, it seems to me that the focus on technique and discipline is absolutely spot on. As Alan Kay memorably wrote:

…there are thresholds that have to be achieved before one can enter various conversations and processes. “Air guitar and attitude” won’t do.

Don’t get me wrong - you need passion (though it’s surely not only passion that carries you through the hard times in acquiring any body of technique). Technique and discipline without passion is a recipe for boredom and mere routine: I’d no sooner want to watch an unpassionate tango dancer than a technically incompetent one. But to pretend that passion is all you need is misleading, irresponsible and disrespectful.

The best lack all conviction, while the worst
Are full of passionate intensity

W.B. Yeats, The Second Coming

And yet … it seems to me that there are many agile coaches whose experience of coaching is limited to working with software development teams. This seems to me a pity: though domains differ, there are many universals around teaching and learning (increasingly, people are starting to understand this at a neurological level, in addition to the social and cultural). Without exception I’ve found the most effective and inspirational coaches working with agile teams have at least one other domain in which they’re either passionate as coaches, or striving as coachees (and of course, it’s not uncommon to be both).

The other lesson to learn is that it’s not enough to be able to coach. Diana Larsen tweeted recently that a good team is one in which everyone can coach. There’s a corollary to this — everyone must also be able to receive coaching. If we don’t practice being on the other end of the coaching relationship, we run the risks of losing touch with what it feels like to be coached, of not being able to place ourselves in our teams’ shoes, and of not being able to connect with their fears, misunderstandings, resistances, nor with their achievements, insights and triumphs.

With thanks to Matt Wynne (snowboard coach), Karl McCambridge (motorcycle coach) and anonymous swimming coachee (if you’re reading this please ping me, credit to follow).

I find the following somehow … familiar …

Modern architecture is hamstring by self-consciousness and strangled by intellectual inhibitions. It is always what people ought to want, and too often what they had better want, or else; almost never what they really want. Everything is done for people, not with them; the whole thing is sick. And meanwhile the penguins walk solemnly up and down their interlocking concrete spirals, a parody of every committee which ever decided about ‘amenity’ or ‘the people’ or ‘urban pattern’. They’re all right, Jack, but we aren’t.

This from a note on the Penguin Pool in London’s Regent’s Park Zoo: it inspired this delicious cartoon by Tom Gauld:

We couldn’t be guilty of this in software, could we?

The sessions on Scala and Clojure were informative, but ultimately frustrating. They ended up being too much talk and not enough doing, mostly down to the presenters’ anxiety to answer specific questions (has to be tempered with keeping things moving for the rest of the group), but also because the sessions didn’t seem to be designed to build knowledge through practice — perhaps, though, too much time on talk meant we didn’t get to the planned lab sessions. The Haskell session focussed on one aspect of the language (lazy evaluation), and was more successful, even though (oddly) it was the least interactive: a first half demonstrated with several code extracts how laziness worked in Haskell, moving from simple to complex: I think I learned more of the operational model in that hour than I’d picked up from any amount of reading before. A second half of live coding worked through an example (solving a mastermind puzzle) step-by-step, more or less a masterclass in thinking in Haskell. Maybe given the mind-shifts that most of us need to make with Haskell this was the best way.

In 2007 Peter Marks and I ran a session called Serious JavaScript — in which we proposed JavaScript as a powerful and flexible language that could be turned to numerous purposes other than browser scripting (with V8 and tools such as node.js it’s good to see it escaping from the browser environment). The session had two parts - firstly a series of conversations, then a lab session we called explorations. The conversations featured what we called ‘an interview with the interpreter” — Peter talked and asked questions, I typed in response (we used Rhino and the Rhino shell, along with Scite with fonts set really big):

Can I print a number?
    js> 42
    42

add two numbers?
    js> 1 + 2.5
    3.5
(all numbers are floating point)

what about 1 + 2 * 3?
    js> 1 + 2 * 3
    7
(operator precedence works as expected)

Division by 0?
   js> 1 / 0
   Infinity

What do strings look like?
    js> 'Hello JavaScript'
    Hello JavaScript

Can we concatenate strings?
   js> 'Goodbye ' + "World"
   Goodbye World
(single and double quotes can be used)

String and number?
   js> "All for " + 1
   All for 1
(operators overload)

And so on, through basic types, arrays, objects, control, functions and methods. If this looks familiar, that’s because it isn’t original: we borrowed the structure from The Little Lisper, Daniel Friedman’s wonderful book on the basics of Lisp (now in its fourth edition, as The Little Schemer):

We interspersed these with four short exercises for the participants: files of code for pairs to play with covering the ideas introduced in the previous conversation: here’s the beginning of the first one:

//---------------------------------- 1
x = 1;
print(x);
// What will this print?
quit();

//---------------------------------- 2
//w;
//print (w);
// What will this print?
// Why is this commented out?
// (Hint - try uncommenting it ... )
quit();

//---------------------------------- 3
var y;
print (y);
// What will this print?
quit();

//---------------------------------- 4
print (yy);
var yy;
// What will this print?
quit();

//---------------------------------- 5
y = 1;
print (y);
// What will this print?
quit();

// . . .

For each point, pairs were to look at the code, try to predict what would happen, try it out, see if their prediction was correct, try to understand what happened if it was not, then comment out the quit() call to move on to the next. Doing this, we covered fundamentals very quickly, setting us up for the second half of the session, where pairs could choose one or more explorations, ranging from the simple (exploring lists and functional abstraction) to the complex (implementing classes and aspects) to the insane (yes, monads!). Here’s one of the simpler explorations:

/*

Using closures to implement objects
=================================
(Grade - easy)

1) Can you write a function called account which
    - takes a single parameter called b
    - returns a function (let's call it M) of no arguments
      which returns the value b

2) Now change the function M so that it
    - takes a single parameter
    - updates b by adding the parameter
    - returns the new b

Is this a little like objects? Yes!

3) Change account so that it returns an object with a single
method called deposit that is exactly the same as M in 2 above, but
doesn't return anything. Add another method called withdraw that
deducts its parameter from b. Add another called balance that returns b.

Congratulations! You've implemented an object programming model! Note
that it enforces encapsulation, which JavaScript's object model does not.

What is the downside of this model?

*/

From our own experience of this session, and from the feedback, we think this is a good way to introduce language ideas. Some key points for us:

• Like everything else, running this session is more fun in pairs. Find someone who’s as keen as you on the language to work with
• Say a few words about why the language is interesting or important, and give a brief outline of its history, before you start
• People need to use the language in such sessions. Syntax on slides and lots of talk doesn’t cut it. The sooner they’re trying things out, the better
• Start simple, and demonstrate what’s familiar before tackling more individualistic aspects of a language (but feel free to throw in a ‘taster’ or two of the more powerful features to get people curious)
• Keep things moving. In the exposition of the language ideas, it’s important not to get sidetracked by the one or two members of the group (there will always be some) who ask challenging or interesting questions. No-one will mind if you say “let’s cover that later” or “we might not get to that, but try it out in the practical”
• Syntax on slides is generally not a great way of getting things across. Show code in an editor or interpreter, then run it.
• Preparation, preparation, preparation. Rehearse the coding (I’ve seen presenters surprised by things not happening as expected in a live coding session)
• A simple copy or one-click install for the environment and materials for the practical sessions is important. Make sure you have versions for the common environments you’ll find on peoples’ machines (OS X, Windows, probably Ubuntu amongst the linuxes), and make sure you’ve trialled the installation and practicals in these environments

The images from the talk are available on the SPA conference wiki here. Maurice’s extended description of patterns of development and habitation in marginal land by excluded communities was exhilarating and moving, and underlined the importance of scale, boundaries, safety. I’m just starting to digest some of the implications (a lot of very interesting thoughts about observation, and the way we see, choose and name patterns): for now here are some smaller things that I found particularly suggestive:

Typhoon house

This is typical of a building in the coastal regions of Bangladesh. These houses belong to families who have escaped the poorest conditions, but in spite of their apparent solidity they are prey to the typhoon that ravage the area. The cost of adapting these structures so that they can withstand storms is actually pretty small — some 10% or so on top of the total. By securing the roofing tiles, separating the veranda from the main body of the roof (so that if it blows off it does not take the roof with it), strengthening the pillars, making sure that doors and windows open outwards so that the wind blows them closed and not open, the house becomes something that a family can invest in emotionally and socially, knowing it will last well beyond the next storm, and which can also be used to raise a loan or mortgage. 10% doesn’t seem so much to pay for such a transformation of family and local economic life.

Independence of structure, redundancy, resilience

The traditional way of building in this part of sub-Saharan Africa is to construct a frame from timbers cut from a large tree. The frame is roofed, then the mud walls built independently. This is a resilient, redundant structure: when the rains come, they wash the walls away, but the roof remains. As a result of deforestation, the encroachment of the desert and climate change, there are fewer and fewer large trees, so these building are now made without a frame, the roof supported directly by the mud bricks. When the rains are heavy, the walls wash away, and the roof of course falls.

Extending the life of a legacy

A caravan in the US. In its prime, a family bought land and moved the caravan to live in. Over the years, the neoprene seals fail, and parts become either scarce or too expensive. The solution: rather than leave the caravan to the elements, surround it with a frame and cover it with a roof to protect it from the rain. Once you have one frame and roof, it’s easy to extend the idea to a roofed porch, whose open sides are later filled in. A legacy dwelling, but one whose value (it’s still inhabited) is preserved.

I liked the idea of using technology and manufacture for what it’s good at: off-site fabrication of small, repeatable, low-cost elements that can be combined in various ways and in various settings on-site. For this to work, these elements have to be small and light enough (can be carried and manipulated easily), have to provide multiple opportunities for fit (to deal with varying needs and site conditions), and have to be customisable on-site. Brick is the classic example, but we also heard about Velux windows, of which Maurice is a fan. Certainly for the work he is involved in, transportation and assembly of large, expensive pre-formed components is not an option: financially or logistically. A small cheer went up when he said he preferred working with craftsmen to engineers :-).

Much of the work at CAT involves building independent parts of a structure — stairs, frame, floor, roof, maybe alcoves and partitions — each restricted to a single local material: stone, wood (local birch saplings or recycled pallets) or others. The components have to have integrity and independent stability, but they gain in utility and meaning when they’re brought into relation with each other to form a structure.

I remember the excitement fifteen years ago of the ferment of ideas around software patterns, and going back to the source to read Christopher Alexander’s pioneering work. I still turn to his books, and Stewart Brand’s How Buildings Learn, for inspiration. Maurice’s talk has rekindled that excitement for me: I’m very glad to have helped it happen.

I hope we’re grown up enough not to grasp any more at any slight similarity between domains of creation and claim that because of these, software is architecture, or software is engineering, or software is craft, or whatever else. Software is software, a rich playground of materials, logical, functional and structural possibilities, with its own unique characteristics. That’s not to say that we can’t be inspired by explorations in other domains. Thinking about problems and solutions in a different domain is a well-established technique for fostering creativity, and it saddens me that much of the way we talk about software and software practice at the moment is either self-absorbed or fixated on a narrow concept of value. And I remain intrigued by the possibility that there are some deep principles of sustainable construction that apply across domains.

One phrase in particular sticks in my mind: Technical debt breeds bugs. This reminds me strongly of the description of the Quality Plateau in the second of the original Programmers Stone talks (it’s about 2/3 of the way down the page. If you haven’t read this already, you really should). The authors — Alan Carter and Colston Sanger — move in several steps from this:

DWORD WINAPI SecondThread (LPVOID lpwThreadParm) {
  BOOL fDone = FALSE;
  DWORD dw;

  while  (!fDone) {
    // Wait forever for the mutex to become signaled.
    dw = WaitForSingleObject(g_hMutex, INFINITE);

    if (dw == WAIT_OBJECT_0) {
      // Mutex became signalled.
      if (g_nIndex >= MAX_TIMES) {
        fDone = TRUE;
      } else {
        g_nIndex++;
        g_dwTimes[g_nIndex - 1] = GetTickCount():
      }

      // Release the mutex.
      ReleaseMutex(g_hMutex);
    } else {
      // The mutex was abandoned.
      break;// Exit the while loop.
    }
  }
  return(0);
}

to this:

DWORD SecondThread(void *ThreadParm)
{
    while(Index < MAX_TIMES &&
          WaitForSingleObject(Mutex, INFINITE) == WAIT_OBJECT_0)
    {
        if (Index < MAX_TIMES)
            Times[Index++] = GetTickCount():
        ReleaseMutex(Mutex);
    }
    return(0);
}

They comment:

Eleven lines vs 26. One less level of indentation, but the structure completely transparent. Two local variables eliminated. No else clauses. Absolutely no nested elses. Less places for bugs to hide. (my emphasis)

Less places for bugs to hide, less opportunity for bugs to breed. These are small-scale refactorings, and today we might make an effort to make the code even more expressive of intent, but nevertheless it’s an elegant and well-argued example of the benefits of clarity. The Stone saw the light of day in 1997 — is this the first published example of refactoring in the wild?

I’d first encountered Jackson through training courses in the 80s on software design — and have to admit that at that point I regarded the rather specific techniques of Jackson Structured Programming and Jackson Structured Design as somewhat old-fashioned: they seemed to be catering for a class of systems that formed a diminishing part of the software ecology, even then. (And I have to add, I was then and am now no fan of people naming methods after themselves or their companies).

But SRP is one of my all-time classics. The title of the book is something of a misnomer: while the ethos of the book is very much around understanding the relationships of the software we build to the circumstances in the world which it is designed to address, it’s structure (a series of over seventy short essays on subjects ranging from ‘Ambiguity’ to the ‘Workpieces Frame’) lets Jackson roam freely over the domain of software development, sometimes specific, sometimes general, sometimes philosophical. The principle of dispassionate methodology (in the section on Method) is particularly apt in the current world of Lean and Agile:

Don’t get your method advice from a method enthusiast. The best advice comes from people who care more about your problem than their solution.

There are clear descriptions of some specific problems (a sweet two pages on the Bridges of Konigsberg, for example, and a description of a — physical — package routing system that kept us busy for a while at Object Designers in the Syntropy days), and more reflective pieces on the nature of description and classification.

SRP introduced the concept of Problem Frames, which Jackson later expanded in a book of the same name. A Problem Frame is a high-level description of the kind of system that’s under consideration, and the way its constituent parts are related to a set of intentions in the world. It has a lot in common with the XP notion of system metaphor: a set of concepts and terms that help us make sense of the system we’re building, and relate the things we’re building to each other and to the system as a whole. Problems arise when we misunderstand the world, and attempt to build a system using a frame which doesn’t fit the solution.

The way in which we tackle development now is, of course, very different from the way it was done in the 80s and 90s. We know now that planning — for example — is a continuous activity, not just a process that produces an artefact. I think we benefit from regarding requirements and specification in the same way: not as documents, but as ongoing processes. If we do this, it’s clear that the need to think clearly about meaning, description, classification, scope and span hasn’t disappeared, but it seems to me that in the agile world we don’t do this as much as we should. Looking at this book again, I’m reminded of the wisdom we’re in danger of losing: who now would take a second look at a book with the words ’specification’ and ‘requirement’ in its title?

I’ll leave you with a favourite extract of mine, a story about software development from the section on Brilliance. Following an in-house course, the DP manager asks Jackson into his office:

“What do you think of Fred?” he asked. “We all think Fred’s brilliant.” “He’s certainly very clever,” I said. “He’s not very enthusiastic about methods, but he knows a lot about programming.” “Yes,’ said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. “Fred did that. It’s the build-up of gross pay for our weekly payroll. No-one else except Fred understands it.” His voice dropped to a reverent hush. “Fred tells me he’s not sure he understands it himself.”

“Terrific,” I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flow chart. That matched my impression of Fred very well. “But what about Jane?” I said. “I thought Jane was very good. She picked up the program design ideas very fast.”

“Yes,” said the DP Manager. “Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn’t really proved herself yet. We’ve given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren’t really difficult at all. Most of them turned out to be pretty simple. She hasn’t really proved herself yet — if you see what I mean?”

I saw what he meant.

• Looking at Bob Martin’s Bowling Game slides, pretty much the first slide says “here is the design”, along with a UML diagram. For me, that raises more questions than it solves (why is that the design? who decided that’s the design? is that the best design? are there others?) — admittedly, answering these questions are not the prime goal of this particular exercise, but I think they’re important questions in software development that we’re in danger of losing sight of.
• Correspondingly, trying Keith Braithwaite’s “TDD as if it really mattered” exercise (in which all code to pass a failing test must be written in the body of the test method itself) forced me to abandon design preconceptions, and started a process of becoming intensely aware of what sort of decisions I was making at every point leading to a “well-designed” solution.
• Thirdly (and to tie in with GOOSgaggle) reading Steve and Nat’s book gives a great insight into the mechanics of TDD, but it’s important not to forget that they (and Kent Beck, and Brian Marick, and Mike Feathers, to name but three…) are all highly experienced developers: their design instincts are honed from years of experience in thinking about and working with object oriented languages and patterns. There’s a strong sense of a “design compass” which pulls their coding and refactoring efforts in the direction of elegance and economy. How do we learn this design sense? And how could we teach others, and teach ourselves, in developing it?

A couple of other inputs are Kent Beck’s recent thinking on Responsive Design (watch this space for something I’m brewing with Peter Marks on this), and Michael Feathers’ ruminations on Design Sense (I don’t share his optimism that we’ll see a revival in the level of design intelligence in the development community at large any time soon).

Gojko has produced a mind-map of the wide-ranging discussion that some twenty of us held (I’ll link to it here when he’s posted it). The conversation was a good start, but perhaps we didn’t go far enough in separating teaching design using TDD as a vehicle from simply teaching TDD.

The key things I took from the session:

Teaching practical refactoring is hard (underlined by Jason Gorman’s experience at the BBC, and my reflections on some of the books and computer-based training tools I’ve seen). Part of the problem is a lack of good examples at the pattern level of design: part of the problem is that a focus on the mechanics of individual refactorings can distance you from seeing or sensing design abstractions at a larger scale.

People will only learn what they want to learn (teaching != learning): in our experience if you want to learn something, nothing will stop you.

Pairing with a view to teaching and learning is important. With a more experienced/less experienced pair, stopping after refactoring and talking about what you just did should be part of the rhythm of reflective practice. More experienced designers should do this with their less experienced colleagues as a matter of course: those less experienced should have the courage and the curiosity to ask why (for example) the refactored design is better. (As it happens I was in just this position recently after guiding a complex refactoring: we both learned from the experience of me explaining).

When you’ve refactored a piece of design or code with a “smell” into a beautiful and minimal version, you’ve also lost something: the smell. Kegan and Lahey have talked about this with reference to change and learning: here, I suggested the phrase “bottling the smell” for collecting examples of things before refactoring so we could replay or reuse the code for our own and others’ learning.

In a peer pairing situation, or indeed working individually, checklists and agreed procedures can play an important part in framing reflection after refactoring. Maybe even just run down the SOLID principles and decide which of these you’ve changed in the code, and by how much?

Pairing is important, but it can’t just be about pairing: we have to work individually on improving our design sense.

Recording a coding session with Camtasia or similar software and replaying it to oneself was an intriguing suggestion which I’ll be trying out (like a musician practicing in front of a mirror).

The requirement to talk about and teach design principles improves our abilities as designers (this is a common experience of those who teach anything).

There’s no shortage of sources for good thinking in design. Most of these are books, some rather old now. Use them.

Review design principles and try coding strictly with reference to some of these (e.g. strict “Tell, don’t ask”, no getters/setters, no state (everything functional)). Restrictions release creativity, and working in this way can reveal the benefits of (for example) the Law of Demeter more powerfully than reading about it.

Anyone out there with practical experience of teaching design sense via TDD? What do you do to teach and learn design?

I came away (as always when listening to Kent) with a whole bunch of insights that have been settling in the days since. One thing that particularly struck most of us was the notion that as you move from monthly to weekly releases, you might lose the daily stand-up meeting, that touchstone of agile practice. To some this sounded like heresy, but Kent’s point was that if you’re going to do weekly releases you’d better all be aware all the time of what’s going on, not just once a day.

Some things falling out of this for me: regardless of structure, the nature and sizes of organisations that are truly capable of real weekly, daily, hourly delivery* has to be very different from what many of us are used to. The more frequently you release, the closer the decision-making about the product has to be to the team making the it, and the closer that team has to be to its users. This suggests to me that the organisations in which these teams work will be small (I’d add — or very decentralised — but I don’t see any of the large organisations I know being able to do this wholsesale decentralisation anytime soon). The more people in a group who need to know (or feel they need to know) about what’s going on, the more time and energy is spent on communication: I wonder whether this puts a limit on the size of organisations with respect to their frequency of delivery. Correspondingly, I think this is a common reason for the sort of friction agile teams in non-agile companies experience at their boundaries.

*”release to an internal production-like environment” is just pretending