XP 2012

Here are some random notes taken during the 13th International Conference on Agile Software Development in Malmö, Sweden.

This conference has a heavier presence of professionals compared to many academic conferences. To simplify I would say that presentations in academic conferences are heavy with content, but on irrelevant topics, while presentations form professional are on relevant topics but are lacking in substance.

Best quote today, from Jutta Eckstein: “A sign of lack of trust is formalism”. In organisations where trust is completely pervasive they tend to rely on formalism, i.e. meeting protocols, process documentation, etc.

Clarke Ching's TDD Test Drive

Tankesaft, a blog about innovation, inspiration and development by Karl-Magnus Möller – only in Swedish.

So far there have been some highlights: Jan Boris-Möller talked about making food from an engineering perspective. He specialises in catering for events, which is quite different form working at a restaurant. It isn’t very agile in the sense that the prerequisites change once the event takes place, but is is very agile since he does not want to keep notes/plans/… from one event to the next avoiding pushing any preconceived solutions to the client. He talked about the order to implement things as a professional chef (colour->…->amount->texture->taste, and not taste first which is the amateur's starting point). He also talked about balancing quality attributes; the client can only have two of fast, cheap and good, but never all three (if you you want it fast and cheap it can never taste good).
Later in the evening he mingled and talked about the necessity of having both experience and knowledge (and they not being the same), and the necessity to educate the client/customer about the consequences of what they order in order to meet their expectations.  Her also wants to inform the guests before eating of the thinking about designing the dishes which he thought enhanced the experience. a lot of developers could learn from this. And yeah, the food was excellent, traditional Swedish resources and flavours in new ways. Definitely the best conference dinner I have had.

One of the most interesting presentations was from Lars Arrhed, a lawyer, talking about contracts regulating agile development. It contained too much information to convey but some a points was: Suppliers (developers) and clients talk different languages. Clients often have a vision of what the resulting product/system should be, which may be very vaguely described in the contract (“Fully integrated system” and “functional administrative system” were two examples from real contracts in court cases). Therefore a supplier should show progress instead of telling about techniques and methods.

I attended some workshops and tutorials on testing and test-driven design. It felt good I could reason about how to refactor a program in a programming language I don't know (Python). On the other hand I was completely stumped when trying to do "wolf-pack programming" in Smalltalk. I could reason about the program in general terms, but it was very hard to write working lines of code.

In test-driven-design I understand the value of producing high-quality code, but the very small loop increments seem almost to hinder elegant designs that are easy to understand.

Where does a good S/W design come from

One of the 12 principles behind the agile manifesto says

The best architectures, requirements, and designs emerge from self-organizing teams.

I have seen cases where I think some teams interpret this as good architecture emerges by itself as long as you follow good practices, e.g. XP, TDD, Scrum, etc. Caveat: I haven’t asked them…
This does not happen in reality. I have experienced colleagues who calls this a “manifested architecture” (every system has an architecture, deliberate or not), in a quite derogatory manner. The common problem with a manifested architecture is that it may fulfil all functional requirements (user stories, features, use cases, …) but does not really support any key quality attributes.
Good design, at all levels, are based on a vision of what the system should be, in terms of functionality/properties and structure. In a self-organised team this is hopefully a shared vision. You can appoint a single person to capture and disseminate this vision (commonly known as an architect), or you can use other principles to define and share the vision. The latter is my positive interpretation of the agile principle above. But you don't hope it happens without concious effort and don't do anything about it...
So how do you learn good design? The best (only) way to do this is to look at other good designs, with as much detail as available. This provides the “type of context dependent knowledge that research on learning shows to be necessary to allow people to develop from rule-based beginners to virtuoso experts”. (Bent Flyvbjerg)

Is there any use of the V-model?

I’m at the 13th International Conference on Agile Software Development in Malmö Sweden. As usual when I listen to presentations these tend to trigger new liner of thoughts instead of pondering the details of what was said. I guess this is a flaw in how I internalise knowledge from others.
Not surprising, nobody here mentioned the V-model. Too bad,since I think it is one of the most important metaphors regarding software (and system) development there is. But it is also on of the metaphors that have been used in ways which are completely inappropriate.
My “condensed understanding” of the strengths of the V-model is this:
It defines a set of activities on the left side of the V with associated artefacts aimed at exploring the problem and detailing the solution down to the actual product (the code!). The important part is that these design activities have corresponding activities of verification & validation on the right hand side of the V, in a one-to-one relationship between the design and V&V activity. The number of levels is individual, but usually about 3-5, including code is reasonable.
Where it goes wrong is when the V is laid out in time as a template for progress of a project. This may make sense if you are designing for manufacturing-heavy products, but is useless for software, the time between understanding the problem (top-left part of the V) and where you verify that your understanding is correct is just way too long to be competitive. This is definitely not news for software developers, and is a key point in agile software development (but probably phrased differently).
But it seems to me that in order to optimise the efficiency and speed there is a tendency to downplay the activities above the point of the V ( the working code). Big-upfront-design is seen as such a bad thing that it ends up in no design at all, there is a direct jump between formulating the problem (e.g. user stories) and start coding.
I believe that in an agile project all activities in a V must be executed in each sprint in order to claim to be “truly agile”. Each sprint means a better understanding the problem, a better design to solve it, and a better implementation in the code. Of course all of these are verified and validated. That does not say that these activates are equally large, or the size of the V is the same in alls sprints, but if you leave out the conscious architecture in the sprints you don’t learn to do better in the next sprints.
You should design the activities in the V to provide the maximum added value with respect to the spent effort, which obviously depends on thousands of context-specific factors), but saying they are irrelevant is only reasonable for the simplest of systems, where you have a definition of the problem and code.
Personally I rather define the result of the activities, i.e.the artefacts, and let the teams decide themselves on how to populate them. I know blog readers may cry about excessive documentation, but what I am talking about is the necessity to externalise  information necessary to share between developers, and teams, and to preserve this information over time, something which code never can do.
Long rant, and I’m not even close the exhausting my thoughts on the subject….