MiniSPA 2007: Better than working

I took yesterday off to attend the 2007 MiniSPA conference. This was a greatest hits compilation of sessions from this year's SPA conference. I almost typed "presentation" but relatively few sessions actually consist of a speaker at the front of the room reading PowerPoint slides to a passive audience. The SPA principles value interactivity and participation. Instead there is a variety of sessions types, most of which involve the audience in some way; tutorials, case studies, workshops, panel discussions, simulations and goldfish bowls. So agenda decisions have another dimension ("how much thinking do I feel like doing?").

The opening session was a think tank. We were divided into teams and each team had to complete the following sentence in no more than ten words:

"Hey, I hear your business depends on delivering software. Well the most important thing about software development is ..."

Each team had to agree on its own phrase; then everybody voted on the phrase they liked the best. The secret of these things is to come up with something snappy and comprehensible. One team came up with a suggestion which had three clauses and used bullet points. That is a dead loss. You can't buttonhole somebody in the corridor and then ask them to wait whilst you boot your laptop and fire up PowerPoint. Here are a few of the final sentences.

• If it's any good, software lasts a long time.
  
• It encodes people's knowledge of the business to provide value.
  
• Get the best project manager you can.
  
• It's about people not computers.
  

That last slogan was the one for which most people voted, thus proving that people repsond to the clarity and focus which abstraction provides.

Designing Collaborative Workspaces

Mike Hunt (Mandu Ltd) led this workshop. Working in teams we had to build models of workspaces out of art card, Lego, Plasticine, Playmobil and various other craft materials. In the first round we had to build a bad working environment, then in the second round we had to build a good workspace. Although each team had a different scenario, the various models had certain common traits. The bad environments all tended to be cramped with people working in fenced-off isolation and with inadequate space for intra-team communication. Fans and other symptoms of poor air-condition featured a lot. The good workspaces were all spacious, with different rooms for different work modes. Bespoke desks and lots of whiteboards were common, and fresh fruit and/or baked goods were provided.

The striking thing was how much closer to real life the cartoon bad environments were. Most of the laughs came from recognition. The good environments on the other hand were largely wish fulfillment, and not just the ready availability of pastries. Floor space is expensive, particularly in London, and I doubt whether most companies would be prepared to devote so much square footage to pamper the developers. It is also unlikely that minions would be given so control over their own working environments. I was also amused to see that I had collaborated in designing an office which was basically open plan. I currently work in an open plan office (albeit cramped), and it can be very hard to concentrate. Sometimes a walled off cubicle seems a very attractive notion,

One interesting aspect of the process was how each team used the materials provided. In the first round we all tended to use the stuff closest to hand. The team with the Plasticine on its table had lots of blobs. Another team had been very creative with card. My team had the Lego so our office was largely built out of plastic bricks. However in the second round we had seen how the other teams had used different materials, so the good workspaces were a lot more heterogeneous in their construction. One team devoted lots of time to writing down the characteristics of their environments. Not surprisingly their models were the least-well realised. An object lesson in the perils of Big Design Up Front.

This session vindicated my decision to take a day's leave to attend the conference. "Logo, Plasticine and Playmobil? And you're trying to say you're working? Get outta here!"

Key lesson: developers want to be free range

Serious JavaScript

This tutorial was an attempt by David Harvey (Sibelius Software) and Peter Marks (indie) to persuade us that JavaScript is a proper richly-featured programming language, and not just a mechanism for undermining the robustness and security of web sites. I'm not sure they entirely succeeded. It didn't take long to discover some quirks in the language. For instance how JavaScript doesn't seem to be consistent in how it evaluates empty or undefined things.

JavaScript is an embedded language. It has no I/O routines of its own and a very small core library. It inherits most of its capabilities from the environment it runs in, which is part of the reason it has such a poor press. We normally come across it in browsers, which are Teh Suck as programming platforms.

JavaScript rarely raises exceptions. For instance strings are immutable, but we can assign to a string without an exception being raised (the assignment is just ignored). Another example: dividing 1 by zero returns infinity, a magic value like undefined or NaN. I suspect this tolerance of wrong code explains why so many JS enabled web-pages seem to hurl.

Key lesson: JavaScript - it's not just for irritating pop ups.

The Scoping Game

The last session I attended was a simulation run by Mark Delgarno (Acumen Software). Again we were in teams. The point of the game was to develop a range of mobile telephones. Marketing had provided us with a list of models, with mandatory and optional features and development costs. Each team started with the same pot of money. The challenge was to decide which features we would develop for a specific product, which we develop as reusable components and which we wouldn't bother with at all. The game was played over two rounds, with our revenue from the first round's models funding working on the second round's new models. Part of the fun was that we only knew the specs for the first three models. So we could hazard guesses about which features would be useful in the second round but we couldn't be sure.

Our team (Yodafone) spent a lot of time discussing the merits of developing Java as a reusable component in the first round, because the marketing brief hinted that it would be on increasing importance in the second round models. However, of the first round models, only one could use Java, which meant a return of a $2m on an outlay of $10m. So we decided instead to develop a reusable SMS component and a product-specific monochrome display for the starter model. We were the only team to bother with the entry-level model (I blame Idiot Toys). But our strategy paid off because Yodafone won the first round which meant we had more money than the others to spend in the second round.

When we got to see the next three models we had to develop a Java component, because it was mandatory for one of the models. However it was also a lucrative optional feature for the other two. So developing it as a reusable component in the second round still generated a profit. Building it earlier would have cost too much money without generating compensating revenue, whereas the reusable SMS component paid for itself in the first round and made lots of money in the second round too. The upshot was Yodafone actually increased its lead at the end of the game. Win or not win, there is no try.

Obviously this simulation is not very realistic. In real life it is often difficult to assign costs and predict returns in such a clear cut fashion. But it was a pointed lesson in making the best of constrained resources. I think something like this game would be helpful as a warming-up exercise to play with users at the start of a requirements workshop.

Key lesson: YAGNI rules in even the unlikeliest of places

Lessons for the UKOUG

Overall I found this to be a very invigorating day. I'll be honest and say that not much of it will be immediately relevant to me in my day job, but the MiniSPA experience gives me some lessons for me as chair of the UKOUG Dvelopment Engineering SIG.

With the UKOUG the rooms always have serried ranks of chairs facing a screen. By contrast the SPA rooms are setup on the presumption of interactivity, with six chairs arranged around smallish tables. In the UKOUG we ask every presenter for their PowerPoint before the day, so we can print them out and put them in the delegates' packs. The feedback form even includes a question about the quality of the presenter's slides. At the SPA only one of the three sessions I attended featured any PowerPoint at all, and that was just to set the scene. The session chairs often weren't presenting at all; rather they were acting as facilitators.

The other thing was that the sessions were about a variety of things. In the UKOUG we tend to have presentations about Oracle's product sets. So it's usually a cookbook format: how to tune a query, how to code a drop down list in JSF, how to call a web service. It's all good, useful stuff which people need to know but it does rather tend to induce a passive receptivity in the audience. By contrast, these SPA sessions tended to deal with practices, and in particular practice improvement. The games and exercises weren't a gimmick: active engagement with the topics stimulated creative thinking, which is the start of the improvement process.

So the challenge for me is to inject some of this excitement into the UKOUG or at least the DE SIG.

The Unanswered Question

In his introduction to the day, the SPA chair David Harvey said that developing software was the third most fun thing we could do with other people. I never did manage to ask him what the second thing was....