I noted last week that we’d given the Code Generation 2008 web site a makeover, including adding the new event logo.

Some gremlins must have got into this process because the new logo showed the dates as 25th-28th June 2008 when in fact they are 25th-27th June 2008. If you’ve got the old logo on your site could you please replace it with the corrected version from the selection available here. (The incorrect version has been available for the past week but is now strictly a limited edition.)

Sorry…

Session proposals are being sought for next year’s BCS SPA conference to be held in Bedfordshire, UK from March 16 – 19.

I’ve taken part in the last three conferences and they’ve been a tremendous source of new ideas for me as well as being a chance to mix with a great bunch of highly experienced people.

One of the good things about the SPA conference is the interactive nature of the sessions. Participants are actively encouraged to engage with the speaker and subjects, typically through solo or group activities in the sessions. You leave SPA wondering why not all conferences can be like it.

The organisers are looking for topic proposals from virtually the entire spectrum of software development. Making a session proposal is a straightforward process requiring you to give a few details describing your session and how it will operate. The deadline for submissions is 17th September 2007.

All sessions are reviewed by members of an experienced panel and their comments are fed back to you so you can see where to develop the proposal further. If you’re accepted you’re allocated a shepherd who will guide you through the process of preparing your session so that you and your participants get the most from it. There’s more information in the FAQ provided by the organisers or you can call +44 (0)870 760 6863 to speak to someone about making a proposal.

Session leaders get a steep discount on the conference and accomodation fees.

ACCU Cambridge’s 2nd talk will be given by Ric Parkin of DisplayLink on the evening of 2nd August...

Synopsis 

memset( &buffer, sizeof(buffer), 0 );

Compilers are very good at spotting syntax errors but cannot help with syntactically correct code that does the ‘wrong’ thing.

Starting with real world examples of such problems, we’ll look at how strongly-typed languages provide a range of techniques – from the humble typedef to dimension-aware type systems, to RAII and ’smart’ types enforcing behaviour – that encode meaning into the type system. These types can be considered as a domain specific language dialect that makes the application programmer more productive, with the compiler catching semantic errors and generating housekeeping code for you.

The talk takes place at DisplayLink, Cambridge UK from 19:00. Entry is free and open to non-ACCU members. Numbers are limited though so please pre-register (not with me!). More details at the ACCU Cambridge web site.

Our graphics designer has come up with a trendy new logo and colour scheme  for next year’s Code Generation 2008 event. So, we’ve spent the last day or so updating the site in line with the new look. See below for the ‘before’ and ‘after’ shots or check it out for yourself here.

	Before
	After

We’ve put a number of variants of the logo on the web site so if you’re overwhelmed with the desire to put them on your site then you can find them here. Thanks

The latest Motor Industry Software Reliability Association (MISRA) news has arrived in my mailbox and it notes that their draft C++ guidelines are now available for public comment.

These guidelines are for the use of the C++ language in critical systems. Their aim is to provide a set of rules that encourage good programming practices and avoid poorly-defined or insecure features of the language.

At a recent talk I went to it was noted that there were a couple of hundred features of C++ that fell into these categories so the guideline authors had their work cut out. However, the MISRA team did have a good starting point in earlier work at Lockheed Martin considering the same problem in the context of the Joint Strike Fighter development.

Production of the guidelines was motivated by an increasing interest in the industry in moving to C++ from C. (note to all you Java/Ruby folks out there – no I am not making this up.)

To participate in the review you need to download the form at http://www.misra.org.uk/misra_cpp_eoi.pdf sign it and return it to MISRA.

A BBC article today notes that a group of Canadian researchers has programmed a computer so that it never loses the game of draughts (chequers) .

The researchers, based at the University of Alberta, began working on a program (Chinook) in the nineties using a heuristic approach with rules derived from expert draughts players.

This approach was successful – in that the Chinook program won the World Checkers Championship in 1994 – however it did still occassionally lose games.

So, they switched to a brute-force approach whereby they analyzed billions of possible game variations to calculate the best move in every situation. With this new approach the program can always play the best move in every situation and so are guaranteed to win – or draw if their opponent also plays perfectly.

Unless you’re a gamer you may not have noticed that the BBC missed a couple of the important aspects of the story.

The first of these is that draughts is a drawn game if played perfectly by both sides. This means that the advantage of moving first is insufficient to guarantee a win.

A second, related issue is that no one seems to have asked draughts players how they feel about this. Doesn’t it somehow take something away from their game by knowing that it has been ’solved’? And what of chess players whose game will now come under greater investigation?

I ran the Scoping Game again at Monday’s miniSPA2007.

This is a simple ‘business’ game that introduces some of the issues in planning the Scope of a Software Product Line i.e. which products and products features to develop as part of your Product Line.

I didn’t count but I think I had 17 people divided into 5 teams – the unimaginatively named ‘Team A’, ‘Yodafone’, ‘Endeavour’, the also unimaginatively named ‘Front-Left’ and ‘SPAPhoneWarehouse’.

In the Scoping Game players take the role of stakeholders – managers, marketers, architects etc. in a fictional organisation about to embark on Software Product Line development. The players are given a fixed amount of cash and tasked with deciding which products to build from a set of candidate products, and which features those products should have.

To help them in this task the organisation’s Marketing group has provided estimates of the market value for each product and the Development group has provided estimates of the development cost of each feature. This includes estimates of how much it costs to develop the feature both as a reusable feature and as a product-specific feature.

Each team starts with the same information, resources and goals but the information is imperfect, for example, there’s some doubt about some of the predicted market values for some of the product features. What’s more the game is played in two rounds and there’s some uncertainty about which features will be needed in the second round which notionally takes place a year later in the company’s existence.

Given this the teams sometimes have to make a judgement call about which products and features to develop and this does result in different outcomes as shown in the picture below.

Yodafone took a narrow lead in Round 1 with their (unique) decision to develop the Starter Phone which no other team developed.

The game always raises issues about how mechanical the scoping process can be, what the business objectives should be (I typically use maximization of revenue when running the game) and whether the future can be predicted in sufficient detail to allow good decisions to be made.

The problem of course is that companies in a Software Product Line setting do have to have a good idea of their operating Scope and cannot simply say the future is hard to predict so we won’t try to. In a real-life setting your estimates will never be 100% accurate so you have to expect uncertainty. The question is how to quantify and manage this uncertainty through principles that maximize your future options – agile scoping if you like.

Here are some pictures of the event, courtesy of Andy Moorley again.

For posterity, Yodafone were the overall winners.

miniSPA2007 showcases six of the best sessions from the annual SPA conference. See here for my post on the Scoping Game session I ran at the SPA conference.

At miniSPA2007 on Monday I joined Mike Hill’s session on “Designing Collaborative Workspaces”. Mike asked us to consider, from our experience, what made specific workspaces good or bad. We were then asked to consider a scenario in which we first designed an inappropriate workspace for our team and then an appropriate workspace for our team according to a predefined scenario.

This process was aided by copious amounts of lego, plasticine, straws, pipecleaners etc – but no sticky-backed plastic as far as I could see. Peter Marks and Nat Pryce particularly impressed with their artistic skills.

In terms of badly designed workspaces some of the following problems seemed to crop up frequently:

• Failure to locate people who work closely near each other
• Furniture that was inappropriate to the task e.g. desks you can’t pair-program at, furniture that’s difficult to rearrange, massive filing cabinets for team’s working with little documentation
• Noisy atmospheres e.g. having piped music
• Having to swipe out / in to visit the toilet
• Lack of communal (meeting) areas
• Lack of whiteboards, wall space for charts etc.

My own personal bugbears include

• workspaces with powerful smells e.g. strong perfume or cooking smells,
• workspaces that are miles from any useful non-work facility,
• workspaces which are through-routes for all sorts of other company traffic,
• workspaces with insufficient storage,
• workspaces which are taken over by others outside the team,
• workspaces that are used as a dumping ground by others and
• workspaces with inadequate heating / cooling,
• on an environmental point, workspaces that are also lengthy or unsafe to cycle to get my thumbs down.

The appropriate workspaces addressed most of these problems – in some cases people had adopted tactics such as cannibalising other items or shifting stuff into other people’s areas surreptitiously. There was a pretty strong consensus for the most part on what made a good workspace including space, plants, windows, wall space for posters/charts, whiteboards and a communal space.

It was a fun session as the photos below (courtesy of Andy Moorley’s mobile phone camera) should show. However it had a serious message behind it. If you have a say in how your workspace is laid out then make sure your team’s needs are being catered for.

Rachel Davies, with whom Mike had run the session at SPA 2007, keeps a track of workspace stories through the Informative Workspace web site. Send her your good and bad workspace pictures and stories.

I’m hoping to get Mike to run the session again for SPA Cambridge. It will be interesting to compare results…

The edited (sound) recording of the Code Generation 2007 panel – UML vs. Domain-Specific Languages – a false dichotomy? is now available at

http://www.codegeneration.net/audio/cgn-episode1.mp3 (MP3 29.4 Mb)

I haven’t set up proper audio feeds yet but will get around to that when I have edited the other two recordings that were made at the conference.

Follow-up discussion is (or will be) going on in the Code Generation Network Forums.

This lively panel considered the use of general purpose modelling languages vs. Domain-Specific Languages. When do the benefits of bespoke domain languages outweigh the advantages of using universally understood notations? Are the two approaches really in competition, or can they co-exist?

The panel was moderated by Andrew Watson, Vice President and Technical Director of Object Management Group. Panel members were Tony Clark (Xactium), Steve Cook (Microsoft), Matthew Fowler (NT/e), Allan Kennedy (Kennedy Carter) and Juha-Pekka Tolvanen (Metacase).

I’m travelling back from today’s miniSPA2007 as I write. It’s a hot, cramped journey back to Cambridge by train but it’s been a worthwhile trip in the end.

David Harvey introduced the day by asking us to consider what we’d tell a senior manager was the single most important thing about software development.

Our group’s suggestions included:

• Hiring the right people (and know how to hire the right people – a good project manager was seen as particularly important).
• Giving them the capability to do the job – e.g. providing them with the right equipment, workspace and letting them define and operate and appropriate process.
• There are no silver bullets.
• You’ll never know as much about it as your developers.

Each group then presented their key idea to the others and we were then asked to vote (by standing next to) the advice that most resonated with our own beliefs.

I felt our suggestions were good but probably not catchy enough to be the winner. I was proved right as the largest number of people, including me, clustered around “Software Development is about people, not computers“. If only everyone understood this…