Soft-Craft

So, on Tuesday night the programme for Software Craftsmanship was worked out. Looks pretty good, I think: there's plenty of the doing sessions that Jason wanted with a reasonable counterbalance of more reflective activities.

I was quite amused by the metaphor collision that's taking place, though. It seems that some people find that the best way to move forward the craft of software development is to head down the dojo for some sparring. I'm far form convinced that either of those metaphors is much help by itself. To see them embedded in one another makes my head spin.

I look forward to the day when we feel secure enough as an industry to have a programming conference where people's ability to do programming is improved. 

Optimism

At the Tuesday Club the other week there was a bit of chat about what seems to be a foundational assumption of Agile: that in fact we can successfully execute software development projects, so we should run them in a way that brings about the greatest benefit.

This in contrast to what appears to be the (undeclared) foundational assumption of many other approaches: development project are so hard that we are most likely to fail, so we'd better find a way to do that as cheaply as possible.

This carried across into a panel discussion at the recent Unicom conference, where one of the attendees came up with this summary description of Agile:

Collaborative optimism to solve the right problems (and only the right problems) in an incremental way

I quite like that "collaborative optimism" bit.

XPDay London Session Submission Process

If you want to propose a session for XP Day London '08 (and I hope that you do), then here's what you need to do.

We want the conference to be largely self–organizing this year, so the submission process is suitably light weight.

Experience Reports

Please send a very brief outline of your report to submissions2008@xpday.org You will receive a URL to a google document. Make sure that you include an email address corresponding to a google account (or let us know if the address you send from is the one to use). The document will be writeable by you and the committee and all other submitters. Develop your report there. As in past years we invite the community to collaborate together to help maximize the quality of all submissions. After the close of submissions the committee will make a selection of experience reports to be presented at the conference. The selected reports will be shepherded between acceptance and the conference.

Conference Sessions

Most of the duration of the conference (other than experience reports) will be OpenSpace. There will be Lightning Talks early in the day where people can publicize topics that they would like to discuss. We encourage people to engage in this way. There will be optional rehearsals at XtC in the weeks running up to the conference. You do not need to attend these to make a lightening talk at the conference. If you would like to have such a rehearsal, send a title and a google account email address to submissions2008@xpday.org You will be allocated to a rehearsal slot. We invite groups outside London to schedule rehearsals too, and are happy to help with scheduling those. There will be a google calendar with the slots shown.

Some kinds of session can benefit from some preparation of materials and some logistics on the day. For example, a workshop involving some sort of server, or extensive materials. There will be a limited number of time slots during the conference for such sessions. Please submit a brief outline to submissions2008@xpday.org indicting an email address associated with a google account. You will be sent the URL of a google document within which to develop your proposal in collaboration with other submitters. After the close of submissions these proposals will be assessed by the committee and suitable sessions will be selected for the program.

We have decided to extend the submission period, so submissions for experience reports, rehearsals and programmed sessions now closes on Friday August 8th 2008. 

This year we want to de–emphasize sessions introducing Agile or Scrum or XP or TDD or... and promote topics of current interest to practitioners. We want the conference to be a forum in which the state of the art is advanced. That doesn't mean that only experts are welcome, or welcome to present. Experts have their failure modes, simple questions from journeymen often reveal the essence. 

All are welcome, so get your thinking caps on!

XP Day London Call

I'm pleased to announce that the call for submissions to XpDay London 2008 is now open. 

Get your thinking caps on, and in due course an electronic submission system will be announced.

XpDay 2008

XpDay London will be on 11 and 12 of December, at Church House in the City of Westminster. The call for submissions will come soon. 

We're aiming for something a little different this year. The conference committee (in as far as it has one) has decided that if we belong to a community that really does value individuals and their interactions more than processes and tools, and responding of change more than following a plan, then our conference should work in a way consonant with that. I'm Programme Co-chair, so a lot of the mechanics of how that will work in practice fall to me to figure out–and this is almost done. I'll keep you posted.

Some Spa 2008 Stuff

Chris Clarke has made a post here exploring the ideas that Ivan Moore and I presented at our Spa 2008 workshop Programming as if the Domain Mattered. Ivan has written up some of his learnings from the session here. I'll be doing the same myself soon. 

Chris makes this most excellent point:

I wish people would be a bit braver and use the code to express what they are trying to do and not worry about whether the way they are doing it is against Common Practice. Remember, the majority of software projects are still failures, so why follow Common Practice - it isn’t working!

Quite.

In other news, my experience report on the effects of introducing checked examples (aka automated acceptance/functional/user/whatever "tests")  gets this thorough write up from "Me" (who are you, Me?) and also a mention in this one from Pascal Van Cauwenberghe.

Thanks, folks.

Agile 2008

Just a reminder that the call for submissions to the Agile 2008 conference closes on the 25th for Feb. I strongly encourage those who are interested in agile methods to go, and I strongly encourage those who are going to submit sessions. 

I'm assistant producer (vice Steve Freeman) of the "stage" called Committing to Quality, which is a home for sessions concerned with the strong focus on internal and external quality in agile development.

I've been watching the submission system since the call opened and there are some really interesting sessions being proposed. Looks as if it's going to be a good conference.

See you there!

UK Conference Season

It's getting round to be conferece season again. If you happen to be in the UK in the next few months, maybe I'll see you at UNICOM, where I'll be talking about some adventures with automated testing.

Or perhaps at QCon, where I'll be presenting the latest news on my metrics work and joining in a panel with Beck and others, both part of the XPDay Taster track, a cross-over from the XPDay events.

Or even at Spa (that oh so magical automated testing again).

Exemplary Thoughts

So, I was asked to write up the "lighting talk" on examples and exemplars I gave at Agile 2007. That was a short and largely impromptu talk, so there is some extra material here.

Trees

It used to be that botanists thought that the Sugar Maple, the Sycamore and the Plane trees were closely related. These days they are of the opinion that the Sycamore and Sugar Maple are closely related to one another, but the Plane is not to either. This is one example of the way that our idea of how we organise the world can change.

As it happens, this confusion is encoded in the binomial names of these species: the Sugar Maple is Acer saccarum, the (London) Plane tree is Platanus x acerifolia, while the (European) Sycamore is Acer pseudoplatanus. Oh, and if you are a North American then you call your Plane trees "Sycamores" anyway. And further more, not one of these trees is the true Sycamore: that's a fig, Ficus sycomorus.

Botanists and zoölogists are the masters of classification, but as we see they have to modify their ideas from time to time (and these days the rise of cladistics is turning the whole enterprise inside out)

Greeks

A well-known dead Greek laid the foundations of our study of classification about two and a half thousand years ago, in terms of what can be predicated of a thing. It all seemed perfectly reasonable, and was the basis of ontological and taxonomic thinking for many centuries. This is interesting to us who build systems, because the predicates that are (jointly) sufficient and (individually) necessary for an thing to be a member of a category in Aristotle's scheme can be nicely reinterpreted as, say, the properties of a class in an OO language, or the attributes of an entity in an E-R model, and so forth. All very tidy. One small problem arises, however: this isn't actually how people put things into categories! It also has a terrible failure mode: as we can see from all this "acerifolia" and "pseudoplatanus" stuff in the tree's names, the shape of the leaves was not a good choice of shared characteristic to use to classify them. It is of this mistake (amongst other reasons) that the unspeakable pain of schema evolution arises.

The Greeks, by the way, already knew that there were difficulties with definitions. After much straining between the ears, an almost certainly apocryphal story goes, the school of Plato decided that the category of "man" (in the broadest sense, perhaps even including women and slaves) was composed of all those featherless bipeds. Diogenes of Sinope ("the cynic") promptly presented the Academicians with a plucked chicken. At which they refined their definition of Man to be featherless bipeds with flat nails and not claws.

In 1973 Eleanor Rosch published the results of some actual experiments into how people really categorise things, which seem to show that the members of a category are not equal (as they are in the Aristotle's scheme), a small number of them are dominant: Rosch calls these the "prototypes" of the category. And what these prototypes are (and therefore what categories you recognise in the world) is intimately tied in with your experience of being in the world. And these ideas have been developed in various directions since.

One implication of the non-uniformness of of categories is that they are fuzzy, and that they overlap. The import for us in building systems is that maybe the reason that people have difficulty in writing down all these hard-and-fast rules about hard-edged, homogeneous categories of thing as many requirements elicitation techniques want is because that's just not a good fit for how they think about the world, really.

Germans

But perhaps examples do. Examples can be extracted from a person's usual existential setting which means that they can be more ready-at-hand than present-at-hand. This is probably good for requirements and specifications (it's not universally good: retrospectives force a process in which one if usually immersed to be present-at-hand, and this is good too). Also, people can construct bags of examples that have a family resemblance without necessarily having to be able to systematize exactly why they think of them as having that resemblance. This can usefully help delay the tendency of us system builders to prematurely kill off options and strangle flexibility by wanting to know the nethermost implication and/or abstraction of a thing before working with it.

And maybe that's why example-based "testing", which is really requirements engineering, which is really a communication mode, does so much better than the other.

I'm proposing a session on this very topic for Agile 2008. I encourage you to think about proposing a session there, too.

Agle 2007

Next time, I'll be writing more about the sessions I attended, and that will have a rather more up-beat tone, since they were pretty good. This post contains my general observations about the conference, though, and they are not quite so good.

So, a somewhat belated write-up of Agile 2007, since I've been as sick as a dog pretty much since I got back from it.

I'm sure that had something to do with spending a week in a refrigerated dungeon. It wasn't clear, upon arrival, where the conference was going to be; the hotel didn't look big enough. Turns out that the conference centre is in the basement. And the sub-basement. And the floor below that. No natural light, no clocks, no external sounds or environmental cues. This plus jet-lag contributed to a disconnected, floating feeling. That and the mammoth programme.

1100 people attended this year, and it is is seemingly the belief of the conference committee that this requires a very full programme to keep them all busy all the time. Individuals and their interactions, eh? No, no, no, session:coffee:session:lunch:session:coffee:session:awkward evening hi-jinks, that's the way. Apparently, next year is going to be even bigger.

And this programme (and session materials) has to be fixed far, far in advance. Responding to change, eh? There's nothing like eating your own dogfood, and is nothing like eating your own dogfood. Trouble is, to get enough sessions to fill that many slots you have to accept a lot of sessions, which means that the bar is necessarily lower than it might otherwise be.

There is no there there

The biggest problem with the venue was that, being spread over three (four, if you count the main hotel atrium) floors it had no identifiable centre, no focus for circulation, so fewer opportunities for the ad-hoc meetings that make these shows so valuable. The nearest thing to a "crush" was the CWAC ("Conference Within A Conference"), a rather half-hearted OpenSpace-ish sort of affair in the most remote part of the centre. More of a "Conference Tacked On The Side Of A Conference" Apparently, the organizers of the CWAC chose that room themselves on the basis that it was broken up by pillars, of which I can see the sense. But really, the committee should have had the intestinal fortitude and spinal rigidity to say "no, we'll figure something out with the pillars, but the place for for the open space is at the heart of the conference."

General observations: fewer "rock stars"; more vendors; more women; more vendors; more non-programmers; more vendors; good international presence; more vendors.

Cheap at Half the Price

Did I mention the vendors? Some years ago I was speaking at Spa, and amongst other things was asked to join in an evening entertainment whereby a bunch of us had to give a speech both for and against a topic. I drew "extreme programming" (which was still a hot topic at the time ;) and one of the points against it that I made was that while it's all well and good that Beck tells us

Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.

but in fact almost everyone in the room was selling something. And furthermore, "no-one", I said, "is going to get rich charging commission on the sale of these things" and I threw the handful of index cards that held my notes for the talk to the ground. Martin Fowler I noticed was nodding vigorously at that point.

Well, these days there are all these folks who very definitely are selling something: great big honking lumps of tool intended to "simplify" the planning, management and execution of Agile projects.

Like Cheese?

So what does that all add up to? I think it adds up to a community that has become "mature". Maturity is one of those concepts that the petit bourgeoisie use to rationalise their fear and loathing of freedom and imagination. This has its up side: a "mature" flavour of Agile is going to be a much easier sell to a large range of large corporate clients (I include government departments under this heading) than the Zen/Hippy flavour, but it doesn't have anything like the capacity to be a radically dynamic force for truth and light in the world. I looked briefly into Mary Poppendieck's session, which sounded very interesting but was completely full and I didn't want to stand for 2 hours. I'm beginning to feel that there's something slightly creepy about the rush to embrace Lean principles in the agile community, because Lean is all about maximising throughput by minimizing waste. Now, most development teams need to improve their production, it's true, but isn't there a bit more to life than that?

Brian Marick was handing out posters listing the items that he feels are missing from the Agile Manifesto, which are: discipline, skill, ease, joy. Presumably, in that order. Doesn't that sound like a good deal?

Tidbits from Agile 2006

These are some items from Agile 2006 which interested me enough that I wrote them down.

Peter Coffee's keynote

• it's a wonder that spreadsheets don't have features built in to deal with uncertainty
• tooling to improve programmer efficiency makes software so much cheaper to write that much more software is worth writing: and so generates jobs for programmers, not the converse
• 3M apparently has a target for revenues generated by products less than three years old
• the value of a codebase is not dependent on the effort that went into building it
• nervousness is the enemy of innovation

An OpenSpace session

• Agile development manifests the Kolb learning cycle
• if you wanted to cerify a team as Agile, maybe you'd only really need to certify the facilitators of the retrospectives
• maybe a retrospective (or similar explicit learning activity) is about deliberately moving from unconcious competence to concious incompetence
• ...and maybe also has something to do with Heidegger's distinction(pdf) of ready-to-hand from present-at-hand. Something that I've had cause to ponder before in its relation to software.

Ole Jepsen's session "Agile Meets Offshore"

• perhaps counter-intuitively, distributed teams tend to have shorter iterations than colocated ones

Laurent Bossavit and Emmanuel Gaillot's session "Tool Words and Weapon Words"

• You are likely in a difficult spot when people start saying things which can be given an "objective" spin but are really claiming the property on the left for themselves so as to imply the property on the right of you:
  
• natural vs artificial
• important vs childish
• life vs death

Owen Rogers' Agile Estimation tutorial

• have the "customer" provide estimates, as well as the developers: when the two are wildly different there's something to learn
• the size of a story as esitmated by the developers is independent of its business value
• the stories that happen to be in a given iteration are a random sample from the backlog

Johanna Rothman's hiring tutorial

• using puzzle questions at interview discriminates against candidates who aren't white upper-middle class suburban American males.
• some white etc. folks find this idea rather upsetting

Ward's Ten Favourite Wiki Pages

• arguing for of refactoring is arguing for your own lack of ability
• if you don't know calculus you aren't equipped to "embrace change"
  

"Agile Architecture" at Agile 2006

Last week I was at the Agile 2006 conference, in Minneapolis and I see from the records that some of you were too: hello again to anyone I met there.

My session was in the first slot after the opening keynote on Monday morning, and I got the impression that some of the folks there hadn't fully grasped what the nature of a Discovery Session was, some other presenters found the same, I think. I believe that the origanisers might do more to help attendees understand better what's likely to be expected of them at such sessions for next year: they aren't tutorials. Of course, my session was a re-presentation of an XP Day session, which like Spa sessions (the other sort I'm used to presenting) tend to be exploratory, open-ended and interactive in a way that the typical Agile session seems not to be.

Outputs

As soon as I get unpacked from moving house I'll have the London reuslts here to compare with, but a selection of the Minneapolis results are here.

The session was bookended by very quick brainstorm to try an capture any change in the attendees thinking after the discussions and work with the lego.

Before

TDD-not fit for mainframe volatile develop platform framework shared direction drives communication developers like complexity correct today testable malleable adaptable think big, start small

standard organic correct today testable design isn't dead! nimble easy to change business engagement high test coverage flexible easy to change dangerous

And a couple of longer items:

• Have an idea of what possibilities your customers may need to explore
• Not for conventional projects, developers know too much business and not only code by success criteria
• provide guide rails for teams to make decisions within

Indeed, developers do like complexity. Given half a chance, they will put wings on a train!

After

experiment results the right solution for the right problem do only what's needed to satisfy requirements testable not holy ground willingness to restart different is OK ROI

cost of implementation time to implement brilliant think big, start small responsive correct today (still) locally optimal flexible (within reason) mutant

It looks to me as if the aims of the session were met.

Some conference wiki also bears some comments on the session.