an entry from

Piotr's R&D blog

I attended CASCON this year, for the first time in three or four years. CASCON is a conference put on and paid for by IBM where academia and industry can shmooze together. Herewith my impressions of this year's event.

CSER meeting

Before CASCON proper, CSER (a better web site is forthcoming) has its semi-annual meeting. The mornings were spent prevaricating about CSER's future, with some debate about various funding models and IP policy. This was not terribly interesting, and while everyone says they find the consortium useful and want to keep it alive, I didn't sense much actual enthusiasm in the room. It's not entirely clear to me what the value proposition is, either: I can meet with other researchers at conferences, in workshops and on-line. Now that CSER has settled on letting each project pursue its own funding, the only things left binding its members together seem to be tradition and the IP policy. I think CSER needs to make its value clear to future researchers: instead of asking graduate students "what do you want from CSER" it should tell them why they should join.

Besides the introspection, a number of groups presented overviews of their research. Many were repeats of previous years, or near-copies of paper presentations from other conferences. The quality varied wildly, with some supervisors seemingly taking advantage of the session as a practice ground for their students' (weak) presentation skills. Two talks stood out in my mind: Peggy did a thoughtful critique of her group's research, which I won't try to relate here, and Jim Cordy exposed the ins and outs of the financial software industry. The main take-away point: minimizing risk has absolute priority in that industry. This means that they still write software in COBOL, they clone code with great abandon and don't try to propagate fixes, and believe that "if it ain't source code (or directly linked to it), it ain't worth my time". The talk challenged many accepted wisdoms of software engineering as taught in classes, and will take me a while to digest. Good stuff.

CASCON keynotes

I attended the Google and autonomic computing keynotes. The Google talk was entertaining, discussing the history of Google and some of its features and architecture. The most interesting part was the description of Google's hardware configuration: tens of thousands of cheap off-the-shelf machines, set up in a heavily redundant network (grid?). These cheap machines can be counted on to fail, with up to 100 biting the dust every day due to overheating, vibration, overheating or what have you. The failures are logged and the machines automatically disconnected from the network, but otherwise Google doesn't care. Every week or so, some attendants amble between the racks replacing failed components (or entire machines). As the boxes come back up, they are automatically reintegrated into the network. The moral of the story is that smart software and brute force can compensate for cheap hardware to your economic advantage.

Contrasting against this approach, the autonomic computing talk painted a picture of self-healing machines that can identify, diagnose and repair faults. This field is very wide, ranging from configuration wizards to accelerometers in laptops that park the hard drive heads before an impact. Right now, there are still more questions than answers. How do you effectively monitor machines or software, if the monitor itself is part of the faulty machine? How do you give high privileges to the automated "doctors" without compromising security? Is it worth your while to invest in this potentially fragile infrastructure instead of going with a Google brute-force approach? As always, the answers are likely to be painted in shades of gray, but this should be a lively research field for the next decade or two.

CASCON papers and workshops

I went to some CASCON paper presentations, but didn't run into anything terribly impressive. I didn't have time to look through the proceedings beforehand, so I picked based on the titles—not the best of ideas. The "best paper" was decent, and Holger gave a good talk about our paper as well. For the rest, I'll just have to read the proceedings.

The afternoon workshops were more interesting. The workshop on aspects had the usual introductory stuff (amusingly, each presenter gave a definition of "concern", all slightly different), but there was more interesting content as well. Adrian Coyler spoke on behalf of the ghostly voice of Harold Ossher about the Concern Manipulation Environment. While the talk was fairly abstract, I look forward to the tool. Adrian also talked about an experiment at IBM U.K. that demonstrated the advantages of aspects over plain object-oriented programming. Adrian and his team took Websphere and modularized some cross-cutting concerns using AspectJ. To make it more interesting, the rules of engagement said that you had to try plain object-oriented techniques first, and use aspects only if those were judged inadequate. The project was a success, and demonstrated that aspects are a valuable software abstraction and that AspectJ can scale to large systems. While I haven't been following the aspect literature too closely recently, this seems like the kind of well-documented result that the field needs to prove itself; I look forward to a publication.

I also attended half a workshop on using Eclipse in education and research, and a workshop on automated reasoning. Both had some ideas of interest, but nothing really to write about. The field of computational logic remains as confusing as ever.

Technology Showcase

As usual, there was also an exhibit hall where both IBM and university teams demoed the latest and greatest software. I was mostly busy staffing our own booth (the Video Bench, which gets its own blog entry), but had the time to run around the floor once. A number of displays were interesting, but the simplest one caught my attention: Designing UML Diagrams for Technical Documentation (scroll down to find the entry). Simply put, it's a short set of simple rules that guides developers towards creating clear, readable UML diagrams. Based on my experience in teaching software engineering, this ruleset is badly needed; all too many novice developers draw diagrams that are both technically correct and completely incomprehensible. Drawing UML is both a science and an art form, and sadly most engineers just aren't artists.