ACCU Conference 2006
Oxford UK

Thursday 20th April

Keynote speech
Helen Sharp (Open) - Software development: a social activity with technical practices

I was pleasantly surprised by this talk, mainly since it's always so refreshing to hear how other people do programming. The main crux of the talk was that programming is fundamentally a social activity, and that aspect is often overlooked. Lots of pictures of programmers working together, and communicating, lots of examples of the different types of interactions that programmers made. Unless you have been living in a box for the past 20 years, this will be nothing new.

What I found surprising is the broad acceptance of agile methods. This is how programmers like to program, unfortunately it is not the way I work at work. Pair programming seemed a lot more common than I have actually seen in practice.

A history of object-orientation was given. A study showed that around 1986, there was a huge explosion of interest and papers in a technology that has been around for 20 years.

The maverick programmer was a very interesting topic. Apparently it is very common for teams to have an "expert", who basically controls the entire team, and likes to be treated like a god. Common traits of these people are to hoard knowledge and rarely document, yet they are still capable of being very productive. Other people dare not do anything for fear of offending of contradicting the maverick. While the quality of their individual work is good, the effect on the team can be disasterous.


Scott Meyers - When C++ Hits the Hardware

I was looking forward to seeing a "Guru" talk, and I was not disappointed. Scott was told to be afraid of the ACCU crowd, and indeed he got more than his fair share of hecklers who really knew embedded programming, better than Scott did. But that didn't matter.

Only two topics were covered - and the bias was definitely towards embedded devices, I was surprised that there was nothing on threading and memory issues, both minefields in the desktop/server.

The first topic was C++ and ROM. The problem is that the standard makes no promises about what ends up in ROM ("ROMable"), versus what must be in RAM. The advantage of ROM is that is is cheaper - there are other advantages too, such as lower initalization costs and being able to share the read-only data segment between processes. A number of examples were given of things that can end up in ROM. Const data, PODs, and stuff with inline constructors and const members. Mutable blows it. It very much depends on the compiler, for example some will ROM structs but not classes. A "trick" is to collate the const PODs into in a struct, and declare that as a static member of a class, which can coerce the compiler. Many compiler-generated data structures can be put in ROM.

The second topic was memory-mapped IO. This is basically volatile memory that doesn't obey the normal rules of RAM. The volatile keyword ensures that the compiler won't optimize away redundand reads or writes. The main example used an enum to reference individual bits, since this is considered more portable that using bit-fields. A wrapper object was created to manipulate the data. Various schemes were presented on how to place the object in memory, including placement-new. Shadow registers were discussed.

What was perhaps the most important principle was how to make the interface to the memory-mapped IO class robust. "Design violations should not compile". The C++ type system was used to wrap addresses, thereby adding a safety check. The destructor was made private. Another important realisation was made, that inline keyword is not about improving efficiency (although it does), but about improving abstraction. Programmers won't be deterred by a performance penalty of adding abstraction.


David Burggraff (Microsoft) - Win32/WinFX integration

This was in part a call for everyone to use Windows Vista and CLR. I has to sit through a little bit of marketing, and then there was a whistlestop tour of programming in the CLR. Many C++ extensions where shown, and how to combine native and managed code. Normal C++ can be compiled under CLR and work every time, and then it can interoperate with managed languages and extensions. Very nice indeed.

WinFX is the official name for "Avalon". It is a new UI library which can be specified either in code or in XML. The XML is capable of expressing complex behaviours. Tools are capable of designing rich GUIs without code, and can generate the XML. Some very nice effects are supported, such as layering and alpha-blending. GUIs produced in WinFX are likely to be much flashier, and easier to write.

WinFX interoperates with Win32. The main part of the talk was to show how easily and seamlessly it was possible to migrate, and mix Win32 code with WinFX and the CLR. As an example, they rewrote part of Powerpoint using WinFX, and also the Hearts server and client. The line-count was lowered significantly for Hearts, while improving the visual appearance.


Bronek Kozicki - Typeless functor
The main objective with this is to create a class that can call a function with data, even though we don't know what the type of the function or argument is. This sounds pretty useful, however no really good examples were given. Scopeguard was suggested, though I was thinking that event handling (for example as part of a GUI) would be a more realistic example. The other goal was cheapness - otherwise why not just use a virtual functor.

Various examples were built up, and there was a lot of staring at code, perhaps too much. The main principle is to create a static templated function, which we can then take the address of. We call the static function with data that was packed into a small block of memory allocated inside the typeless functor object. The major problem with this approach is that it only works for PODs, which in my opinion is too restrictive. But unless you expose types, there is only so much you can do.

The main power with the typeless functors was the ability to copy data about, and to access the argument in a typed way by comparing the address of the function, which is a cheap way of doing RTTI. The number of arguments can be mixed, currently 0 or 1.

The main drawback with the approach was that it falls in between tr1::function and boost::any. It only works for PODs, which is hardly modern C++. The scopeguard example was particularly uncompelling since normal scopeguard implementations just use a reference and can work with any data types whatsoever with no performance penalty. However the technique of using a reference only works for local scope - you can't copy opaque data.

Some good comments came out, for example why not initialise the functor with a "null" function, or a policy-based null.


Agile with Offshoring - Panel with Jutta Eckstein and Nico Josuttis

This was completely unexpected, since the format was a discussion with 5 people in the middle of the room, and people could sit in the main discussion chairs at any time, with the only rule that if one person enters, another must leave. This was quite a fun way of doing things. However since I have no experience of offshoring, I did not enter the discussion.

The discussion was to try to establish best practises, and understanding, of the combination of two extremely widespread phenomena (at time of writing) - Agile development and Offshoring.

The main issue was that offshoring has huge communication overheads. Thus, although there may be gains in terms of reduced salaries, the teams will work much less effectively due to communication problems. Other problems cited include hugh staff turnovers in offshore companies, and that key developers in the main company spend a lot of time training people up only for them to leave.

Such difficulties had lead some companies to abandon offshoring completely, once the math had been done.

It was questioned whether offshoring is at all compatible with agile development. Agile relies on enhanced communication, something offshoring cannot deliver. How can one pair with somebody 6000 miles away? The main issue is trust, since people tend not to trust people they have never met. Offshoring is a management decision which developers rarely support, while agile is a development decision that managers often don't support without persuasion.

Agile also involves developers meeting customers, which clearly is not achieved. If agile cannot work as such distances, should projects be split such that entire projects are taken offshore?

A large challenge is cultural differences - in some cultures people always claim to understand something, and say they are able to deliver, even though they cannot.

A point was made that the audience was very biassed - none of us has been developers in developing counties. Offshore developers feel very used and resentful of their oppressive employers, and it is not surprising since they clearly are being treated as second class. Overseas developers do not want to be programmers, they want to quickly progress to management, and into better paid jobs. As soon as they increase their skills, they are out. Programming is not seen as a career.

Working relationships are very important, and very difficult to foster at such distance. Nevertheless it is important to try to make friends.

There is a conundrum. Open source software is extremely effective, extremely global, and extremely agile. Perhaps the main difference is that open-source programmers treat each other as equals.

There was no real conclusion, other than that offshoring hinders agility.