miniSPA is the little brother of the BCS Software Practise Advancement conference, held over 3½ days each spring time. Instead of 2½hr sessions with breaks in the middle, we get one day of 75min condensed versions as a taster to the main event next year. And it’s free!
Each of the sessions was interactive in its own way — some depending on the attendees to provide content, other involving them in exercises and others just inviting discussion about a particular experience that was present. I went to one of each type and they were all well presented and food for thought.
Best Practices for Finding your way into new Projects - quickly…
Marina Haase
This was a workgroup session in which we were invited to brainstorm ideas and experiences that help us understand and get involved with a new project.
First of all Marina gave us a run-down of some the ideas that had been raised in the main SPA conference earlier in the year. These are covered on the SPA wiki, but the ones that caught my attention were the following three:
- Watch out for guru fear: the team you are joining may be apprehensive of new experts joining them — will they be told that what they are doing is wrong?
- One way to defuse this fear might be to find areas where the existing team does things better and to mention those areas of expertise; another might be to find experts in the existing team and go to them for help
- Prepare questions beforehand — and make sure you take time to ask them
- It’s all too easy to get wrapped up in the work and to hurry with your integration, but taking a step back is often very useful
- Write down things in your own way
- Don’t just rely on existing documentation — take a notebook and write down descriptions in your own language. Writing things down can often be a better way of understanding them than just reading other people’s descriptions.
We then went on to brainstorm further ideas for getting into a new project quickly. The most interesting part of this bit of the session was the brainstorming techniques themselves — we were invited to try one of three methods, though all the groups in the room chose the same one: Metaphorical Brainstorming.
I’ve never come across this before, but it’s a great idea (and good fun too!) — instead of brainstorming directly on a subject, think of a loosely parallel situation and brainstorm ideas and techniques for that instead. Once you are done, spend some time figuring out how each of your ideas might apply in your original problem domain.
The brainstorms that worked best were the ones that took a slightly unusual scenario (one further away from the original problem) and then pushed it to its extremes. These generated ideas that we wouldn’t have thought of otherwise and gave the group a lot more energy in the brainstorming itself. A useful technique that I may end up using if a brainstorming team shows signs of flagging.
Sid and Nancy apply for Life Insurance: Storyboarding the Domain Model
Justin Forder
The second session I attended was a more traditional presentation, but discussion was encouraged from the start and the presentation evolved directly with the wishes of the audience, skipping some slides and focussing on others.
The topic was a new style of diagramming aiming to bring the domain model of a complex system to life. Often the domain model can get fairly big and complicated. While it is (usually) understood by the people who built it, the model can be difficult to describe to new joiners, and discussion of requirements and restrictions with the business team can be subject to misunderstandings. UML diagrams such as sequence diagrams and use case diagrams are meant to help here, but they can often be too detailed or too abstract to make sense without an existing understanding of the system.
In contrast, there are a lot of techniques used to bring the user interface to life — as this is the only way that it can be evaluated. Justin’s idea was to take one of the techniques from user interface design, storyboarding, and apply it to the back-end domain model.
A storyboard looks like a cartoon, consisting of a sequence of snapshots each showing an instant of the story and hinting at the movement within each frame. In user interface design, you would create a storyboard for a detailed, concrete scenario, with clearly defined actors trying to achieve specific goals.
Justin applied the same technique to the domain model resulting in a sequence of diagrams showing how the model is populated and how it changes as different actions occur. The final document told the story of the system in a way that lots of different people could understand; it was a powerful tool for new joiners, but also extremely useful for testers. Justin even used the same technique to help identify performance bottlenecks caused by repetitious actions.
In order to make the diagrams more complete, Justin invented some simple annotation styles which are well described in his actual presentation. This will probably make its way on the web via the SPA wiki at some point..
This storyboard is not intended to be the only documentation of the system. There are several areas, such as encapsulation and polymorphism that it does not show at all. Drawing the diagrams won’t particularly help to design the system in the first place — but it does help to exercise and illustrate an existing design.
The differences between this process and specific UML use case diagrams also raised a point about testing: it’s useful to remember the difference between use cases and scenarios when writing unit and functional tests. Scenarios have specific values and tell an end-to-end story. Use cases are more general — they often capture a lot of error cases — and are more individual.
Overall, storyboarding the model looks like a very useful tool for getting an overview of a bigger system and I will look out for opportunities to take advantage of it.
Effective Pairing
John Daniels + David Cleal
The final session I attended at miniSPA 2008 consisted of a series of exercises to evaluate the effectiveness of pairing. The exercises were intended to cover different kinds of tasks — analysis & planning, social situations, physical activities and creativity. Each activity was worked on by both pairs and individuals so that we could compare and discuss the advantages and disadvantages of each approach.
The full version of the workshop allowed everybody to try all the exercises, but the cut-down version we were getting at miniSPA, only had time for each person to try out a couple of the activities. This was a great pity, as the physical exercise involved putting together a Lego model, and only two groups (not including me!) got to have a go.
I found the exercises themselves very well designed — useful source material for helping teams to understand the benefits (and sometimes drawbacks) of pairing. The planning activity in particular worked well with a pair, surprising some people who had only thought of pairing in development. At Kizoom, we try to do all our estimating and project planning with at least two people — errors caught here save not only the planning time but also the development time.
The social situation exercise was a role play of a personnel issue, with a project hampered by a troublesome guru. The group I was in found that pairing was good for the managerial side of the role play — one had time to think and a chance to moderate their feelings while the other was talking — but could be more threatening for the interviewee. On the other hand, having a one-on-one conversation meant that the conversation was more personal rather than about the issue at hand. There were some people in the session who said their companies had a policy to always have a third party in the room for personnel issues.
I really hope that the session organisers publish their exercises and the results of the questionnaires they asked us before and after each exercise (possibly here). Personally, I didn’t find my impression of pairing changed that much due to the session, but then I really like pairing already and am fortunate to work in a company that not only accepts it but recommends it as a practice.
