ACCU 2009: So many sessions, so little time...

Preamble [21st April 2009]

Well, we're here at the Barcelo Oxford Hotel again, and for us ACCU 2009 starts tomorrow (though the pre-conference workshops happen on the Tuesday, we haven't booked onto one this year).

We are a little more prepared this year than last - for example we now have a 6 foot roll-up banner, better printed materials and a pair of Q9550 quad core machines configured as a networked code analysis demonstrator. All of that adds up to quite a load to move (and we obviously do not want to leave equipment unattended during the night), so we are expecting to have a bit of a rush around to get everything set up and ready after breakfast each morning!


(in case you are wondering, the two quad core boxes are under the table and controlled from the keyboard on the left).

Day 1: Wednesday

After breakfast this morning we headed to the sponsors hall to set everything up. As we had a rather more elaborate stand this year it took us something like 45 minutes to get everything ready.

That done we had a little time to cool down a little, mingle and generally catch up with those we know from previous years.


Keynote: "The Birth of Craftsmanship" (Robert C. Martin) [Slides]

This morning's keynote was "The Birth of Craftsmanship" with Robert Martin (aka "Uncle Bob"). Robert is the author of Agile Software Development, Principles, Patterns, and Practice, a book which I can wholeheartedly recommend to anyone wanting to learn about modern software development practices.


The theme of this keynote was the changing perceptions of the nature of software development over the past 40 years, and where our perception of what we do might be heading.

He opened with a rather memorable quote: "In the beginning, the expectation was that you could throw specifications into a room, then throw in meat (i.e. programmers!) and code would come out". This of course evolved into the belief in "Big Plans" or "Big Up Front Design" prevalent from the 1970s to the 1990s (and of course that didn't work either...).

Things have changed a lot since then - and today we have accepted ways of developing software which work very well in practice (when companies deign to use them correctly - far too many still don't, unfortunately).

Robert's assertion is that we should now accept that software development is not (as has so often been supposed) science or engineering - but instead a craft. As such, very different rules apply - rules to which we as a profession have not yet adapted to.

Following an interesting diversion into Wave-Particle Duality and the Uncertainty Principle, he then gave a fascinating history of the evolution of software development practices from 1992 (Jack Reeves assertion that "Architectural blueprints are analoguous to source code, not the Big Plan") through the arrival of the patterns movement in 1995 and the Agile Manifesto in 2001.

As a late arrival to the party, I found the history fascinating.

Robert suggests that "Agile is the gateway to craftmanship and to a profession" and predicts that the next big thing will be the realisation that the only way to go fast is to go well, and do it right in the first place! i.e. for developerss to have a Profession and therefore Ethics ("no, I will not write bad code"). Although laudable, that's a lofty ambition - particularly when you consider the mass of undertrained developers out there and the tension between increasing skills (which implies higher rates of renumeration) and commoditisation of software development skills.

One of his more controversial (or is it...?) assertions was that the rapid adoption of Scrum among development teams is not likely to significantly improve the success of software projects generally unless Scrum itself evolves to include the technical practices of agile software development (notably TDD, measurement of team velocity and potentially pair programming) it omitted from XP. Time will tell, I suspect!


Agile Makes Progress Transparent - but who wants to be confronted with reality? (Jutta Eckstein)


Jutta's session was an informal discussion of human factors in software development, and some of the tensions which can arise if an organisation or team is unwilling to commit to learning (it doesn't have to be formal training, of course), trust (a lack of which often results in excessive formality) and quality.

Change (in particular in software architecture) is a fact for developers, but businesses are often afraid of it. Hence, communications with stakeholders should avoid inappropriate detail and use appropriate terminology for the listener. Conversely, organisations often fail to accept what they are advised is really possible, despite being told. There is a tension between innovation in business and what we as developers believe is realistic.

I'm not going to even attempt to detail all of the topics discussed, but they included issues such as the optimum size of a development team (5-7 people), ways to rescue a failing team (in general adding more developers will make things worse rather than better - Brookes Law) and how Stable architecture is a bad idea (the design must be able to evolve with the requirements).

To me, the closing statement really said summed up the number one issue those advocating software quality face:

"Agile is very often a trouble detector, and although it only exposes issues which exist anyway, this is often not welcome, and as a result the process gets blamed. One way to expose this is to perform a retrospective on the project - showing the true picture.

"Ultimately, key people need to give a damn. If that is not the case, no amount of process will help."


Introducing Parallel Pixie Dust: A Novel C++ Threading Library (Jason McGuiness ) [Slides]


Jason is well known in ACCU for his expertise in parallelisation, so this session (in which he presented a library which can be used to parallelise operations on data in standard STL containers in a lock free manner without risk of deadlocks or race conditions) promised to be a fascinating discussion on the subject (and one which built nicely upon the discussion on the subject we'd had in the pub the previous evening...).

He didn't disappoint, and if you are at all interested in the subject I really suggest you take a look at the slides.


Panel: Programming in a Multilingual World (Kevlin Henney, Steve Love, Russell Winder and Ric Parkin)

This session discussed issues relating to multi-programming language development, including which languages each of the panel suggested a new developer should try to learn (always an interesting debate!), and what drives the adoption of new languages in organisations.

At this point I should own up to the fact that as I'd been rushing around trying to get everything ready for our stand I'd not had a chance to read the session programme to learn what each session was about. Consequently, I'd assumed that it was about internationalisation....


Welcome Crappy Code - The Death of Code Quality (Nicolai Josuttus) [Slides]

Nicolai is the author of The C++ Standard Library, and in this session he made the deliberately controversial assertion that inevitably globalisation and increasiing commercial pressures will lead to even crappier code and buggier systems. In effect, this is the strawman to Robert Martin's "Software Craftsmanship" session.

The strawman is a simple one:

1. Code quality is not possible
   
2. Accept that it happens, and react accordingly

Whilst I accept the second premise (I'm a pragmatist after all!) the first is one that's easily disproved simply by studying teams who do it right in the first place....

Day 2: Thursday

Keynote: "The Benefits of Abstraction in Patterns" (Linda Rising)

This morning's keynote focused on Linda's personal experiences with patterns, and is loosely based on a paper she wrote for IEEE Software. She described what she does now as "I think about how people think, and how they solve problems".

Her session described her journey from developing specific technical patterns through corporate behavioural patterns to abstract patterns for improving (for example) peoples lives in third world countries. The latter teaches us an important lesson - when introducing change you must take local conditions into account if you want the change to succeed.

The session began with a history of the pattern movement, beginning with the publication of the "Gang of Four" book at the OOPSLA conference in 1994 where it was met with absolutely huge demand. Quote obviously, it touched on a rea pain point for many developers present. A particular strength of the GOF book is of course that the concepts presented are both language and platform independent - they are about re-using ideas rather than any specific implementation. In her own words: "ideas captured in patterns are timeless".

She then moved on to describe the process of submitting a patterns paper to a PLOP conference, and how the experience (which is based on writers workshops) differs from that used in most conferences, before describing how she has gradually became aware that patterns could be applied to the process of introducing change to organisations. In fact, her book Fearless Change originally started in 1996 as "Patterns for introducing patterns into organisations" (metapatterns?). Since then it has evolved into patterns for introducing any type of change - it does not have to be a technological change.

Linda also described what she saw as "the abstraction dilemma" - do we have lots of detailed patterns for each domain, or far fewer more abstracted patterns, and illustrated this by the response of the Ada community to the GOF book: basically "nothing here applies to us" for the trivial reason that the examples were not written in Ada...


Controlling Project Risk by Design (Niels Malotaux) [Session Materials]

I actually ended up in this session by accident (I couldn't get into Kevlin's session at the same time) but I'm so glad I did. Niels' presentation was humourous, useful and interesting (exactly the same reason I try to hear Kevlin speak, in fact!).

The session focused on defining and controlling risk during the design process, using an iterative self-leaning approach known as the PDCA or Deming cycle.

Key points included:

• Most real risks are in the product, not the implementation. Hence,if you can control the risks in the project you will have more free resources to cope with product risks (which are often much less predictable).



• If a defect is a problem experience by avstakeholder, then it follows that:
  
  1. Not satisfying the project goal is a defect
  
  
  2. Being late is a defect
  
  
  3. Being over-budget is a defect

I have to say that I particulary like his approach to defects...


Code Analysis Tool Parallelisation and Grid Computing (Anna-Jayne Metcalfe) [Slides]


This was an informal ("BOF") session I'd put together just before the conference as a direct result of conducting benchmarks on the parallelisation (both local and network grid) of PC-lint analysis tasks, and the issues this raises in task scheduling - particularly if PC-lint 9.0 precompiled header support is also used.

The benchmarks are those we described in the blog post Visual Lint/IncrediBuild case study and benchmarks, and were performed while writing the Accelerating PC-Lint C++ Code Analysis case study for Xoreax earlier this year.

The most interesting part of this subject for me is the promise that PC-lint precompiled headers hold for reducing analysis time (always an issue with large codebases) and the corresponding implications for the scheduling of analysis tasks. In particular, running a PCH enabled PC-lint analysis "on the grid" requires very careful scheduling if it is to be faster than the non-PCH equivalent. Notably however, the scheduling requirements for PCH are far simpler for local analysis, and our benchmarks certainly reflected this.

A fascinating subject, I hope you will agree.


Multithreading in C++ 0x (Anthony Williams) [Slides]

Dealing as it does with one of the most compelling areas in the forthcoming C++ standard, this was (not surprisingly!) a very popular session. In it, Anthony gave a rather comprehensive (or at least it seemed so to me) introduction to the new threading capability introduced in the new standard.

The C++ 0x threading toolkit is based on boost::thread, and deliberately basic. In essence, it comprises:

• Thread launching


• Mutexes


• Condition variables for blocking waits


• A clearly defined memory model - allowing safe use of atomic variables without thread locks


• Futures for high level concurrency design


• std::lock() - which allows multiple mutexes to be locked simultaneously with a guarantee to not cause a deadlock.

Futures are very interesting, and to my mind are the single most compelling feature of the new standard threading support. A future is a "token" for a value which will be available later - allowing the developer to focus on communications rather than locking access to a shared variable which will contain the result.

Anthony gave an overview of the various new standard types, including std::unique_future, std::shared_future, std::packaged_task (whose value is the result of a function call), std::promise (where a value set explicitly) and std::async (a possible contender for the standard, in which a library manages a thread for the function call) and gave examples of each.

Overall, the session illustrated well the fact that multithreading is hard - but it isn't the threading itself, it is the communication between threads and the unpredictable effect locking can have on performance. C++ 0x threading promises to make that just a little easier, and I for one am looking forward to being able to use it in anger.

Day 3: Friday

Keynote: Geeks, Nerds & Other Prejudices (Susan Greenfield)

Susan Greenfield - or Baroness Greenfield if you prefer formality - is one of Britain's leading female scientists, and to be frank it felt like a bit of a coup for ACCU that she was able to speak for us at the Conference.

The subject of her very entertaining keynote was the experiences and perceptions of women in technology - with all of the stereotypes, misconceptions and so on that subject raises.

Susan started by debunking common myths such as "It's all genetic", "Girls don't like science and technology", "Girls are bad at science and technology" and "Female scientists/technologists are 'not normal' by using a high level (but extremely interesting) description of the structure and operation of the brain to illustrate how such simplistic and naive such misconceptions really are. To quote: "In such a complex system it is simplistic to assume that genes constrain behaviour".

She then descibed commonplace traps which can lead women to underachieve, such as confidence (women are less confident and less likely to emphasise their strengths than men), conflation of personal with professional (women and men use language differently, and women take conflict more personally), not finding the right mentors (they don't have to be female, of course), social factors such as lack of availability of childcare etc.

I found this to be a very entertaining and enlightening session, and judging from the reactions of the rest of the audience I was far from alone!

Panel: Women in Technology (Astrid Byro, Anna-Jayne Metcalfe, Sue Black, Frances Buontempo)


I was honoured to be asked to participate in this panel. Susan Greenfield was also meant to be on this panel, but unfortunately she had to rush off for another engagement at the last minute. Regardless, she set quite a stage for us, and the discussion was extremely wide ranging, covering topics as diverse as the effect of corporate culture on the advancement of women within an organisation to social conditioning and family expectations. We could quite easily have carried on the discussion for hours - 45 minutes really wasn't enough to do the subject justice.

The fact that I felt safe enough in that environment to talk about my experiences of socialisation and gender within the trans community was testament (in that community, female technologists outnumber the male ones) to how safe and diverse an environment ACCU represents for female technologists. As a transwoman myself, this is not a subject I discuss lightly, believe me!

After the panel I had quite a few people come up to me to thank me for participating in it, so I'm glad I took part, despite my nerves beforehand.


Bletchley Park Presentation and Appeal


During the lunch break (did I mention ACCU lunches last 1 1/2 hours...?) there was a presentation on the history and possible future of Bletchley Park (the site of a groundbreaking codebreaking effort during the Second World War, and the location where computing as we know it began).

By this stage I was starting to flag so I didn't take any notes, so I hope Allan Kelly will forgive me for reproducing what he quite eloquantly said on the subject in his blog:

Several activities this year were designed to support Bletchley Park]. A donation scheme, a raffle, challenge puzzle and a sponsored bike ride (thereby hangs a long story.) In keeping with this theme Simon Greenish from the Bletchley Park Trust and Dr Sue Black from Westminster University gave a talk at lunch time.

The history of Bletchley Park is increasingly well known. Simon and Sue focused on the future, how they trust wanted to improve the park and the difficulties that stood in the way. The key point was that the trust is now in a race against time, the buildings are decaying and need repair if they are to be preserved at all. There are still enough Blethchley Park war veterans alive to make historical projects based on the park worthwhile. Before long much of our history will be lost if we do not act now.

Certainly it was enough to persuade me to make a donation to the Park, and hopefully I?ll go and see it this summer. And....

IF YOU ARE READING THIS BLOG PLEASE SIGN THE PETITION TO SAVE BLETCHLEY PARK NOW http://petitions.number10.gov.uk/BletchleyPark/.

Designing 'Good' Components, Interfaces and Contracts (John Lakos)

John Lakos is the author of Large Scale C++ Software Design, and the originator of the well established ACCU tradition of "being Lakosed". If you work with large C++ systems, you really should have a copy of this book on your bookshelf.

His presentations are always interesting and thought provoking, and this was no exception. This session covered four particular areas, each in significant detail:

• Physical design (files, libs etc)


• Interfaces and contracts


• Good contracts


• Proper use of inheritance

Unfortunately there was far too much material to take detailed notes on, so if I find a link to his slides I suggest you read them carefully. Much of what John said I agreed with, but not all, of course!

Day 4: Saturday

Keynote: Principles for Successful Software Management (Allan Kelly)


Allan is an ACCU regular, and well known as a speaker who eloquently puts "the case for effective management" to balance the more commonplace technical perspectives within ACCU.

In this keynote Allan sets out key considerations for better management of software development.

Developers often see the management of software development as a dark art. While the tools and technology constantly race ahead, software management is all too often stuck in the 1950s.

Alan observed that the continuous minor course corrections we all make in the course of our work are more important than "the big stuff" which organisations typically may most attention to. Furthermore, the quality of the people involved is key - as Fred Brooks famously commented in The Mythical Man-Month":

"the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take."

One critical - but all too often overlooked - point is that someone has to give a damn (and it must be someone who actually understands development...). Companies appoint managers to be that person, with widely varying degrees of success. Unfortunately bad management can all too easily destroy a projec - and in fact bad managenent is actually worse than nothing...

So, Alan proposes that we need a management philosophy, and some principles to follow:

1. Know your customer, what their problems are and what they need and want


2. Features, Resources and Time are relatively fixed, but scope can be controlled


3. Quality is free


4. Management by Routine (not exception)


5. Stay Connected


6. Risk Management by doing


7. Continuous Improvement


8. Trust & Honesty


9. Its the people, stupid!

Legacy Code - Learning to live with it (Pete Goodliffe) [Slides]

This session was on the Saturday afternoon, and by now everybody was flagging. Although Pete's presentation was every bit as entertaining as ever, I was struggling to keep my eyes open. It was still worth it, as the photo below shows rather well(apologies for the poor contrast, it was the best I could manage at the time):


Need I say more, other than to ask:


So that's it for another year. We've had a great time, caught up with old friends and even learnt a littlelot.

If you didn't go this year, I hope you'll take the time to attend the conference next year and learn something new. Believe me, your code will thank you if you do.

Photos from this year's conference.