Building Successful Communities of Practice

Just got back from a stimulating evening meeting of the BCS SPA specialist group. The presenter was Emily Webber on Building Successful Communities of Practice. If I understood correctly, a community of practice is a cross-functional, self-selected group of practitioners doing roughly the same tasks in different teams, business units or even organisations. Spotify has identified almost the identical concept in its "guilds".

The big takeaway for me (apart from the fact that Emily in real life doesn't look nearly as similar to Sarah Millican as she does in her photo) was that the mutual support provided by such a group gives people more autonomy and more mastery of their craft, both of which are strong motivating factors and promote happiness, which in turn results in demonstrably higher productivity and lower staff turnover (a study by Warwick University showed the productivity of happy employees to be 10-12% higher than average, while that of unhappy ones was 10% or more below). This would seem to suggest that allowing as much as one day a week to employees to exchange ideas and experiment with ways to improve their technique could be a worthwhile investment.

Inspiring the next generation of developers

Jason Gorman has published a thought-provoking opinion piece asking why schools are doing so little to promote IT as an enticing career option and to equip kids to take advantage of it. His analysis points to a lack of suitably qualified teachers (so what's new?) and a commensurate lack of ambition on the part of exam boards to make the syllabus industry-relevant.

Do get in touch with Jason to take part in a summit at Bletchley Park (where else?) on 25th August 2011 to identify practical measures that can be taken to improve this dire situation.

I think this is an issue the BCS should be addressing with all dispatch instead of tying itself in knots over some elusive ideal of making all IT practitioners professionally qualified. Some of the most proficient software practitioners I know have no professional qualifications at all.

Software: Craft or Trade? You decide

Dan North has started a serious discussion with his insightful article about the Software Craftsmanship movement and where its manifesto possibly misses the point.

Turn any program into a Windows service

Today, Oisin Mulvihill introduced me to his company's open source product, Service Station. It's very simple, very effective and stunningly useful. I am really surprised that it isn't much better known. With one short shell command, you can install any script or application (headless, command-line or GUI) as a Windows service that can be started, stopped and managed through the Services control panel. As a bonus, Service Station restarts programs that have crashed, cleans up all spawned processes when stopping a service, and provides comprehensive logging via the Windows Event Viewer - it really could not be simpler for the system administrator. It is suitable for every version of Windows from 2000 onwards.

BCS SPA2010 conference

Final day of the conference - it's gone much too quickly as usual. My favourite session to date has been the brief whirlwind tour of agile practices given by Gwyn Morfey and Laurie Young of New Bamboo - "the Sword of Integration". This was a highly interactive session that involved everyone standing up and moving about enthusiastically, which despite the cramped room, meant that we all ended up remembering something instantly useful from the session.

By the way, the sword of integration itself is just one example of an instant solution to a pressing problem. The situation was that multiple developers checking in their changes would cause each other to have merge conflicts. The solution: a paper "sword" quickly assembled, which when held conferred on the holder the right to check in - and hit anyone who checked in when they shouldn't. The principle being illustrated is "just try it" - there is no need to get it absolutely right first time. If it doesn't work, we can change it later.

Craftsmanship for Teams

Very interesting discussion thread on Software Craftsmanship as a team exercise. In response to Cory Foy's posting, Steven Smith makes an interesting analogy with coaching a sports team and says how that is actually carried through in his practice.

Software Engineering Best Practices

Tom Gilb recommends Capers Jones's latest book Software Engineering Best Practices. From my quick reading of the preface and introduction, it certainly looks like a thorough piece of work!

Test-Driven Design is not testing

I've recently worked with a team doing its first agile project (though one or two team members had been involved in an agile project before). The most difficult concept to get across was TDD - test driven design. I found that people really didn't grok the idea until I pair-programmed with them for a couple of hours. I wonder why that might be.

Dan North has suggested one possibility. He observed that newcomers to TDD often don't get the really big payback because they continue to think that TDD is mainly about testing - even if they will admit that writing the tests before the code leads to better quality code. They never transition to treating TDD as a design process, letting them discover the API to a component they're writing, nor to the realisation that TDD is about defining the behaviour of their component and its interactions with other components of the system.

Keith Braithwaite has put forward another consideration. In physical engineering disciplines, practitioners speed up their work process by using gauges. There are many kinds, from the simple spark plug gap gauge, which is simply a sliver of metal to slide between the electrodes, to electronic vernier calliper gauges that can be pre-set to a precise dimension with tolerances above and below. Each workpiece is tested at each stage of the process by checking its dimensions with the appropriate gauge(s). Workpieces that are out of tolerance are sent back for rework or scrapped. Our unit tests are a bit like that - they provide a safeguard that the software component we're working on still meets all its requirements following any engineering we've done.

It occurred to me today that unit and acceptance tests, particularly if automated, perform another valuable function in the context of an agile (especially a lean) development process. Whereas the waterfall processes familiar to most developers are characterised by "quality gates" at key stages, every single artifact in an agile development has its own little quality gate, manifested in the appropriate tests. This theoretically frees the development process from the usual bottlenecks that the quality gates tend to become.

I say "theoretically", because in many instances agile development projects have to take place within a quality system that doesn't take advantage of incremental delivery. Instead, continued approval and in many cases funding for the project tends to be contingent on passing the traditional quality gates following requirements analysis, functional specification, high-level design, low-level design, coding, integration, system test and acceptance. Project managers are therefore forced to conjure up some kind of spurious linkage between the milestones laid down in the rigid quality system and some arbitrary points along their product release plan. This can hamper their freedom to adjust the release plan in response to changing circumstances and emerging technical insights.

This could be avoided if the quality system could recognise that properly written tests represent every work product of a software development project apart from the code itself. It should therefore simply insist on a verification at each iteration (or at each release, perhaps) that the tests comprehensively and comprehensibly represent the requirements of the business on the system under development and that the required set of tests pass repeatably. I say "the required set" because there's always the possibility that some tests will intentionally fail - e.g. where they have been written to test features that are not yet in the current release.

In other words, TDD can be used to eliminate the quality-gate bottlenecks of quality systems that assume waterfall development processes.

Distributed bug-tracking in Haskell

At the recent SPA 2009 conference, there was a lot of talk about functional programming, Haskell in particular (a couple of years ago, the flavour of the month had been Erlang). Just to prove that Haskell is no longer "just a research language", along comes DisTract, a distributed issue-tracking system that runs in Firefox browsers. If you're already using Git, Darcs, Mercurial or Monotone as your distributed software configuration management solution, the author reasoned, why shouldn't you be able to close bugs while you're off-line at the same time as you check in your fix? Caveat: I have not tried this yet, but it sounds like a really neat idea. Does anyone know of a user forum?

My Favourite Keyboard Shortcuts

That was the title of a session I proposed for today's first-ever Software Craftsmanship Conference, at the BBC's attractive Media Centre in London's White City. To my surprise, the session was accepted. It worked quite well despite attracting only about half a dozen participants. I certainly learned a good deal from it!

The output of the session has been posted on the conference Wiki. However, you'll have to be logged in to see it, as the wiki is private to conference participants. I don't know if Jason Gorman plans to change this now the conference is over.

The top tips (as a result of a quick spot vote at the end) were:

The three-step refactoring tango: Jason's recipe for method extraction where one or more parameters are themselves method calls. In Eclipse, it goes ALT-SHIFT-L (extract local variable), ALT-SHIFT-M (extract method), then ALT-SHIFT-I (inline local variable as method parameter).

Expand/shrink current selection: In Eclipse, ALT-SHIFT-up/down arrow or in IDEA, CTRL-w/W. With the cursor on a given word, the word is selected. Repeated applications of the same keyboard combo selects progressively larger portions of the source file (up to and including the entire file). Using the opposite key combination reduces the size of the selection all the way back to 0.