Title: ACCU Conference 2005

I was inspired by Pete Goodliffe to write up some of my experiences from the ACCU conference in Oxford last April, as he did in the June issue of C Vu. Unfortunately the deadline for that issue whooshed past before I was able to get it finished, but perhaps that's not so bad as it means you get two consecutive issues containing conference reports.

These reports are based on the notes I made at the time, so if I have reported anything incorrectly you can blame me for not paying proper attention during the conference sessions. I hope they give a taste of the kind of things you can learn about in the formal sessions (you can of course learn many other things in the informal "sessions" in the hotel bar and the pubs of Oxford!) I have only omitted a couple of sessions, and that's because those were so interesting I didn't make good notes!

I would like to point out that all the sessions I attended were worthwhile and interesting, a testament to the ability of the presenters and relevance of their subject matter. I didn't fall asleep once, not even in any after lunch talks!

The first keynote speech of the conference was on the subject of security, a subject of course that has heightened importance in these days of script kiddies, phishing, DDOS, and other such threats. It was also a keynote on the subject of Open Source vs. Proprietary software, a nice controversial subject guaranteed to get the conference delegates talking on the first day of the conference proper.

After struggling with failing audio amplification, Ross posed the question: Which is better for security, Open or Closed systems?

In order to try to answer the question he turned to statistics and mathematics, and made an analogy between thermodynamics and software development, where the number of bugs in a software system is the analogue of the temperature of a physical system. At first I feared the mathematics would make this a rather dry keynote, however this wasn't to be and Ross moved on, making the speech more interesting as it progressed.

According to Ross it turns out, rather controversially, that open and closed source systems are equally good when it comes to finding and removing vulnerabilities (bugs) in them, because the statistics shows that the benefit from the undoubted increased initial rate of bug finding in the open source world is cancelled out in the closed source arena.

Having dropped this bombshell on the open-source advocates in the audience, he qualified this with the phrase "in an ideal world", and pointed out that nothing is black and white - various factors affect this equivalence, then becoming the first to mention one of the phrases of the conference, "Symmetry breaking". Then Ross moved on to report real-world experience backing up his findings, and empirical studies designed to identify the best approach to bug finding and fixing.

Concluding, Ross compared the process of software development with that of medicine: It started out as rather a black art, known only to initiates, but is now big enough to enable statistical methods to be used to help all of us.

In a packed Cartoon room, Pete started off by nearly alienating his audience when he said, "There are a lot of dross programmers out there!" Of course everyone in the room knew he was not talking about them, was he?

To get his audience involved, Pete then plucked several volunteers from the audience, not all of whom were called Alan (or Allan), and proceeded to use them to create a simulation of a software program. This was great fun and involved ultimately several threads passing data, in the form of a ball, around.

This generated much discussion and quite a bit of heckling from the audience, not for the first time in this talk. However the fun was now over and Pete moved on to his slides, beginning with a diagram showing a target with "the individual programmer" in the middle. I don't think this is what was intended however, as the idea was to show levels of teamwork - the main theme of this session.

The message from this talk was that software development management structure affects code, at least the "code shape". To clarify this, Pete listed seven team disasters or diseases, followed by a discussion of the opposite - team health.

Finally we were urged to use one of Pete's action sheets to actually go and achieve something positive as a result of this talk. Hopefully some people actually did this!

In this session, Jutta talked about how planning fits in to the Agile software development methodologies' short release cycles. The assumption seemed to be that most of the audience were at least fairly familiar with the concept of the Agile methodologies, but to be sure, Jutta began by reiterating their main points. The one that stood out the most was that "working software is a measure of success".

Moving on, the session proper began by discussing the short "time boxes" used in Agile development, and in particular, what was the best day of the week to finish each time cycle. Aided by two energetic members of the audience, both of whom were called Allan (or Alan) Kelly, it was quickly established that whatever day you settled on, it shouldn't be Friday.

Jutta continued on the discussion of various considerations when planning Agile projects. Many of these seemed like common sense, but like much good advice you don't always think of it until after the event, so having it presented in black and white is helpful. An example of a common sense point is, when requirements change - and they will -- don't try to control all four of the following factors: Time, Project scope, Resources, and Quality. It seems obvious but many people working in traditional methodologies would try, and fail. Leading from this is the idea that fixed-price projects are BAD, but realistically they are common, so you must plan to vary the scope or the time of such a project, but not both!

The key point underlying most of the principles is that your plan should be result-oriented, in other words you aim to deliver working software to the client. After discussing the planning of the Agile project's iterations, Jutta moved on to talk about measurement of results and reflection on past iterations or releases. Such feedback is vital in planning the next iterations.

Summary: Remember, requirements WILL change, this is not a bad thing because it means the customer knows more clearly what he or she wants. However this means we can't begin with "a plan", but rather engage in the activity of "planning" throughout the life of the project.

Aeryn is a C++ test framework Paul developed to help him test his software. It can be used for unit-testing but is not specific to this function. Apparently it's named after a character in a television science fiction series.

Aeryn makes heavy use of macros, which Paul decided to state up-front, in case any of the audience had "a problem" with that. No-one did (or were brave enough to admit that they did) which was a relief as otherwise the session could have digressed straight away into a holy war over when and where to use macros.

A multi-layered approach is used, and Paul began at the bottom level, describing the Test Conditions he has implemented (with macros!) that allow you to put tests in your code using such expressions as IS_EQUAL(LifeTheUniverseAndEverything, 42).

The next layer up is that of Test Fixtures, which are functions and classes containing Test Conditions. Next, Test Cases are wrappers for Text Fixtures. Finally Test Runner is an object to which Test Cases are added

Once a Test Runner has been created and appropriate Test Cases added to it, it can be invoked, whereupon it will run all the test cases and generate a report of each one's success, or otherwise. Finally it will return an overall status which can help when scripting automated runs of test cases.

Paul then showed a simple example using Visual Studio .Net. and engaged the audience in discussion about the reporting features. He also showed how Aeryn could be extended to generate custom test reports.

Finally, because this talk was a relatively short one, Paul decided to fill the time with a discussion of a testing technique called "Mock Objects". This is not related to Aeryn but Paul included it as it's a useful testing technique.

This was always going to be a popular one, and it paid to turn up early. As one might have supposed, the hall was packed with expectant delegates eager to hear what news the founder of C++ had to bring.

Bjarne started off with a threat to mobile phones. Suffice to say that people hurriedly turned theirs off in fear of being singled out.

On to the real subject of the day: C++, or to be more precise, the current state of the language and how it can (will?) be improved to better support generic programming.

The ability to do generic programming with C++ through templates has had a major impact on the development and use of the language. Templates, both through the STL, and through metaprogramming, are a big success and make many programming tasks easier. But there are problems, which Bjarne described as "the language is straining" under the effort. Certain error messages are an abomination, and some uses of templates simply require too much brain power!

Bjarne stated that the aims of the language additions he was describing were to support generic programming and templates. He described the following three areas for improvement:

This two-presenter talk followed on from the Bjarne's keynote, and dealt with similar items, ie. changes we can expect to see in the next C++ standard, expected within 10 years (not that long in ISO standard-time!).

Bjarne began by defining the problems faced by the standards committee when trying to "fix" C++. Namely, that people want improvements but you can't please everyone and we also want stability.

So why change? The language must adapt but carefully! He described a list of "rules of thumb" to be followed by the committee with the intention of minimizing problems with new features.

After the talk, Bjarne opened the floor to questions, and some discussion on the merits of deprecating features followed, before he gave way to the co-presenter of this session, Herb Sutter.

As if Bjarne wasn't sufficient draw, the first session was combined with a talk by one of ACCU conferences most popular speakers. Herb, as he often does, had given this talk a subtitle - "The Concurrency Revolution". His point was that concurrency was "here", and is a revolution on the scale of "the OO revolution". By which Herb means, and I quote directly, "It will change the way you write software".

One last quote from the introduction to make the point: "The state of the industry is terrible!"

Herb really, really wanted to get the point across that concurrency is a big issue and getting bigger. And if we're not careful it's going to be a big problem. He began a list of truths by by describing the fact that Moore's famous law just didn't apply any more. A "wall" had been hit and we can't have faster single-threaded programs any more. Instead, through innovations like dual-core processors and Hyperthreading, we get faster multi-threaded programs, which means we all have to learn to be multi-thread programmers.

The next list after Truths, was Consequences. This was all about issues with memory models (we need guarantees), locking (broken!), and something about Santa Claus and elves that I haven't come across before!

Finally, appropriately, was the list of Futures. Herb pointed out that non-mainstream languages are better but this doesn't help the majority of programmers.

A thought-provoking talk.

Continuing the day's theme on the future of C++, Francis began by explaining that the C++ standard committee was known as SC22-WG21 and if we want to have a say, we should get involved, urging us to Google for that string of characters.

Now began the list of proposals under consideration for the next version of C++, beginning with the Forwarding Constructor. This brings the much-desired ability for one class constructor to forward to another at the initialisation stage, rather than having to call an ordinary member function from the constructor body. However it also raises the question of when is the class considered to be complete? When one constructor has finished? When ALL constructors, including any forwarded to, have finished? This subject is still under discussion.

Another proposal Francis described was the idea of Explicit Classes. These are classes that have no automatically-generated classes (copy constructors and so forth). The idea is that there will be switches to explicitly re-enable the generation of these functions.

Francis then described a couple of features that are on hold because of overlap with other proposals, before finally mentioning the idea of extended "switch". Currently the C and C++ switch statement can only use constant integers for the case values. I have known people familiar with other languages, where this is not the case, express bewilderment at why this should be so. This reaction is commonest with newcomers who want to switch on a string, and can't understand why they can't put a complete string value at each case. Francis proposed relaxing this rule and allowing more flexibility. Just how much is yet to be decided - should we allow variables as well as constants? In that case why not allow any expression at all. Then the switch would be transformed into simply "syntactic sugar" for a multi-level if-else statement.

Allan presented a highly-interactive session in which he presented his idea of how software development and learning are related.

He started by noting that the solution domain (eg. of C++), the application domain, and the process domain ("how we build software") overlap and interact.

Next Allan spoke about learning. Software is the embodiment of knowledge, and learning continues after development has finished. Why is learning important? - because it can enable us to get better software.

The next point led to an audience discussion. Allan stated that learning creates change, and change creates learning.

There was much discussion of points covering information, knowledge, action, problem-solving, and different types of learning (single-loop, double-loop, with triple-loop introduced into the arena by Jim Coplien in the audience).

Now, Allan introduced a phrase to describe bodies like the ACCU: Communities of practice. This is a better term than something like "society", to describe a group which is not an official professional body or guild or suchlike, but which develops standard practice in the industry and encourages learning.

Finally there was more discussion, this time with a whiteboard, in which Allan solicited ideas from the audience for how to improve learning.

It was a very thought-provoking talk, and different in some ways from the majority of conference sessions. Many people left the room saying what a success it had been.

In another packed keynote, Cope (as he tends to be known) warmed up the audience with a display of amusing slides, including some pictures of Bjarne Stroustrup and Kevlin Henny looking very bizarre indeed. The reason for the bizarreness was that the pictures had been altered so they were completely symmetrical, that is the left side was a mirror of the right side. This neatly and amusingly illustrated that although we tend to think that we are, humans are not really symmetrical.

Cope continued by talking some more (actually rather a lot) about symmetry. He demonstrated that a starfish displays another type of symmetry (it's symmetrical when you rotate it by 72 degrees).

That example was used to point out that there are quite a few different kinds of symmetry. In computing we tend to think of structures of "blocks", rather than the UML diagrams we are encouraged to use. These blocks are symmetrical and regular. In computing symmetry is the holy grail, but he also pointed out that broken symmetry leads to beauty. This was backed up with some quotes from Christopher Alexander, the originator of the patterns movement in architecture, which has been taken up to enthusiastically by some of the computer science community.

Returning to the idea of symmetry, via a rather funny joke he had been told about Iraq and the United States Constitution, Coplien described the physical process of k-meson decay, which broke an underlying symmetry and was apparently responsible for the overal balance of matter against antimatter in the universe. Consequently, he suggested, God is left-handed. A wag in the audience asked whether He drove on the left too!

Finally returning to computing, there are many design methods that break symmetry. C++ reflects reality by allowing us to express broken symmetry. In this respect reality is messy - or, since the symmetry is broken, is it beautiful?

According to Frank Buschmann, Model-Driven (software) Development, or MD(S)D, is motivated by "the software crisis". Software development is expensive, and despite multi-structured and component services design, complexity hasn't gone away.

MDD uses a domain-specific language to specify a model of the system to be implemented, then uses a model compiler (that is, a compiler of models, rather than a model of a compiler) to generate code that implements the system.

Models can be built using common modelling tools such as Visio, XML, or others.

Frank described a two-step process of building the concrete design: step one takes the previously-mentioned model, and various performance, scalability and architecture requirements (and so on). This generates the architecture. Then step two generates a concrete design, code and configuration.

Naturally, what you get out of it depends on what you want and on the domain. As you might expect, and Frank emphasised, the model must be extremely precise. It takes a lot of up-front effort. Although it apparently removes the need for coding, MDSD should not be seen as a silver bullet, but as just another software development method.

Frank described some apparent disadvantages of the method, such as:

Following Frank's description was some discussion with the audience who were, perhaps understandably, rather sceptical. Contributions were made by the usual suspects - Henny, Jossutis, Stroustrup, one of the Allan Kellys.

After this, Frank conceded the audience's point that MDSD was probably not worth it for single unique software projects. Where it stands up is when the architecture and model can be re-used for different applications within the domain.

Finally Frank noted that there were several implementations including the OMGs MDA, OpenArchitectureware, and Microsoft Software Factories.

Concurrency was one of the topics that cropped up several times in this conference. Herb Sutter named it as the next big thing in computer software development, and so this talk was rather popular.

Hubert started by noting that not much progress has been made in concurrency development. We still use the same old Critical Sections, Mutexes and Semaphores to implement the locking and checking that's required for safe concurrent programming. And it's still hard.

Next he asked the question, "What do users want?" There are often unexpressed requirements such as "it must not do Y" rather than "it must do X".

The next question is, "What do clients want?" Using the example of a price lookup for a shopping or catalogue system, what is needed is a guarantee over time that the price won't change unexpectedly (i.e. in the middle of a transaction). Note that the concurrency being described here is that of a client and server both accessing the same data.

Four types of locking were described:

Questions are raised - in the case of two clients making changes to a database record, which one "wins"? The one that read the record first? The one that makes the write first? The one that read the record last? Or the one who writes the record last? Arguments can be made for each. Again, concurrency is hard.

Finally (at least according to my notes) described the so-called Heisenberg Triple. This is a familiar type of statement that gives three criteria and tells you, you can have two out of the three, but not all of them. In this case the three options are Client consistent with server; Client has data available; and Client is independent of the server.

To finish with a quote, to achieve a compromise between all of these, there is usually some "acceptable window of unsynchronisation".

As it was for the other keynotes, the hall was packed on Saturday morning, despite following the Speakers Dinner the night before. Somewhat appropriately, Kevlin began by describing how this talk was the result of a pub conversation, the details of which are available in Kevlin's blog at http://www.artima.com/weblogs/viewpost.jst?thread=5432

The five considerations of the title are five points that Kevlin came up with in the aforementioned pub conversation, when asked for advice for beginners in software design.

The first of them is a restatement of the "Less is more" sentiment familiar to readers of Kevlin's articles - "Less Code, More Software". Those readers will be aware that Kevlin sometimes likes to speak in sound bites, at least in his talks and articles, and for this point he excelled with "remove to improve", but, "Don't encode your code". In other words concise code is good so long as it's readable.

The second of the five considerations is undoubtedly the recurring theme of the conference, "Symmetry". Kevlin pointed out that normally, symmetry is seen as good. However this is not always the case and sometimes it must be broken, a point made by Jim Coplien in his keynote.

The next subject for our consideration is "Spacing". In other words, separation of concerns, frequently touted as A Good Thing in object-oriented software design. This time it came with a warning to avoid too much separation, resulting in Fragmentation (A Bad Thing!) It's also concerned with making your code easy to read through the sensible use of white space and suchlike.

"Visibility" is the next consideration. Software is aphysical. As Kevlin pointed out, we can't use our physical intuition about it.

Lastly, we must consider "Emergence". This refers to so-called emergent behaviour in which a few simple rules produce apparently complex results. One of the classic examples, and the one described by Kevlin, is birds flocking. A few simple rules like "follow your neighbour" results in the ability of huge flocks to sweep gracefully across the sky all apparently knowing where they are going. In software terms we are being told to use simple rules and mechanisms such as polymorphism rather than complex sequences of "if" statements.

Finally, it is important to remember that these considerations are not rules or recommendations, but just as the word suggests, things to consider.

In this presentation, Lois used her experience of being thrown "in at the deep end" when having to implement an XSLT (XML stylesheet language and templates) project, to communicate the absolute minimum you have to know to get up and running, and productive, with XSLT.

A sampling of the points Lois made:

Lois spent a very useful couple of hours showing how XSLT works, with several sample stylesheets. All in all it was a useful talk that I believe everyone who attended found useful.