After weeks of keen anticipation, not to mention many long nights of preparation for my own session, SPA 2011 has now been and gone.
Overall it was an excellent conference with a great group of attendees. The numerous inter-session conversations I had with fellow attendees were as enlightening as the sessions themselves.
Here are my thoughts about the sessions that I attended.
Monday 13th June
HTML5 Boot Camp
This session by Laurie Young and Ismael Celis was one of several focussing on the hot topics of the moment, HTML5 and JavaScript. After a brief introduction to HTML5 and what it provides we got cracking with the exercises.
Working in small groups we were asked to implement a web page that allowed the user to drag an image from the file system into it. The next task was to upgrade it to get the image(s) to persist when the user refreshes the page using local storage. Finally we were asked to use a web socket to send the image to a pre built server which would then distribute it to everyone else viewing the same web page.
There was a reasonably large range of JavaScript experience within the session, however I think most people managed to complete the exercises. It provided a great introduction to several of the most universally helpful HTML5 JavaScript APIs.
Improving Trust in Teams
Rachel Davies’ session looked at how to improve trust in teams.
Split into groups of four we were encouraged to discuss our various experiences of both low and high trust scenarios. Perhaps unsurprisingly most of the scenarios that were highlighted involved low trust. Once each of us had relayed our own trust stories within our groups we were invited to share the most interesting ones with the wider audience.
Afterwards we resumed working in our groups to draw force field charts that highlight things that we believed help to improve trust and those things that hinder it. We drew these up on a flip charts and again shared our thoughts with everyone attending the session.
Finally we looked at one of the forces behind improving trust and what we might do to nurture it.
It was an enjoyable session that has really made me start to realise that there are perhaps more facets to trust than I had previously considered.
At the Extremities of Extreme
This catchily titled session by Julian Fitzell and Jason Ayers was a fascinating introduction to the theory behind wolf pack programming. This technique takes the familiar pair programming, but turns it up a notch, taking collaboration to a new extreme.
I can barely do the concept justice here, but my simple interpretation is that with adequate tool support developers can collaborate without having to be sat around the same PC if they work on precisely the same instance of the code. The tools would allow a developer to see which functions/methods the other people working on the code base were looking at or editing. This allows pair programming to be followed where appropriate, but the navigator can slip off to do some driving if they think of something that will help to remove a block that they have observed that the driver is about to encounter. They also advocated judicial use of spikes to hunt out the quickest solution to a problem.
They had run an actual wolf pack programming session on Sunday which I am now disappointed that I missed.
At the moment the example sessions they have been running use Smalltalk, however my thoughts are about how we might trial these techniques for JavaScript development.
Invited Rant
John Nolan entertained the conference audience with a rant against the term “software engineering”, specifically that:
Software engineering does not and should not exist
He reaffirmed Kent Beck’s statement that:
Software is software
He conceded that:
Software is like engineering
But saying it is engineering is wrong. Instead he introduced us to a different metaphor:
Software is cooking
The examples he provided were very compelling, although even John conceded that he wouldn’t be changing his business card to read Software Chef just yet.
Tuesday 14th June
Unfortunately I missed most of Tuesday’s event as I was preparing for my presentation the following day, which leads me to…
Wednesday 15th June
Web Apps That Shine
I co-presented this HTML5 focussed session with my colleague Adam Iley. The specific context for it was the features of HTML5 that allow up to build web apps.
We introduced the offline support that is provided by HTML5, including local storage and the application cache. Afterwards the attendees paired off and worked at upgrading a n0tr, simple note taking website, to work offline.
The second section highlighted the tighter integration we can now get between a web app and the device it is running on. On mobile devices access to geolocation, and the device orientation is available, whilst on the desktop we can implement drag and drop both within the web app as well as to and from other applications, including dropping files into the page. Again we asked the pairs to upgrade the n0tr app to use some of these techniques.
We concluded by talking about portability and other concerns for building and releasing web apps. The presentation is available online as are the exercises that we ran.
Invited Rant
Jason Gorman’s rant was titled Slow and Dirty.
It was a thought provoking view on our responsibilities as developers with plenty of statistics to help back up his points. When starting on a new project the features come in thick and fast, however over time productivity starts to plateau. On the 8th major release of a major product (no names mentioned) the cost to write or change a line of code was 20 times as much as it had been initially.
Making our software maintainable is our responsibility, and is not something that we should abandon in our quest to keep adding new features to keep our customers happy. We need to be prepared to pace ourselves for a marathon, not a sprint.
Finally, beware the statistical aberrations that seem to have flouted all of this advice and are major successes nevertheless. Just because your great aunt smoked 60 cigarettes a day and lived to be 103 doesn’t mean that to give yourself the best chance to survive to 103 means that you should smoke 60 a day.
Specification By Example: By Example
The final session I attended was run by Lasse Koskela. Lasse asked us to split up into groups of three, then handed out an index card to each group that specified a requirement for a particular software system. Within our groups we needed to capture the specification by writing or drawing out the various examples we could think of.
My group was asked to produce the specification for an email verification system. We sketched out the interaction between the server and the user, defining 5 different scenarios that we could think of, one of which covered a hacker.
Two members of each group were asked to switch over with people from other groups. The remaining person on each group was asked to explain the examples they had drawn up to the new members, and we were asked what improvements could be made.
Finally everyone changed groups again, moving onto a requirement that none of us had worked on before. We are asked to review what had already been done, then start afresh and come up with our own examples.
Overall the session went very well and it was interesting to see how much would be achieved in a very short period of time by sketching out the examples with tight collaboration between all the members of the group. There was a warning flag though that the lifespan of the examples that we created was limited as there was contextual information that was only available to those who were involved in the conversations surrounding the creation of the examples – a little more structure might be necessary if these are to persist over a long period of time. Nevertheless this was a technique that I’ll be trying out at some point soon.