The CSMR 2009 proceedings have been published; within it you will find the latest paper produced by the CROSS team. The paper has also been added to the Lincoln eprints service.
CSMR
CSMR – Day 3
And so CSMR concludes. Still recovering from the conference dinner (surreally hosted in the Hotel Alcatraz, which used to be a prison — and that’s not a joke). Enjoyed it here, conversed with some really interesting chaps, and one or two personal heroes.
Let me wrap up with some bite-sized snippets:
- Acceptance rate of papers: 31%
- Best paper award: “Incremental Clone Detection” by Nils Gode and Rainer Koscher
- Special award: Harry Sneed (“for leadership and many contributions to the practice and principled growth of software maintenance techniques and their industrialization.”)
- Population of Kaiserslautern: 100,000 approx.
- Time I have to wake up tomorrow to begin my journey home: 0545.
CSMR – Day 2
CSMR 2009 soldiers on.
Today’s keynote was delivered by Tibor Gyimothy which looked at software metrics from the developer’s point of view. He presented the results of a study where developers were surveyed for their opinions on various metrics.
The developers were divided based upon such attributes as experience, platform knowledge (Java, C/C++, C#, SQL), and open source participation. They were questioned upon their opinions of metrics that measured size, complexity, coupling, and cloning, and the results were analyzed for correlations. The kinds of questions included “which metrics effect your understanding”, or “which metrics affect the testing effort”? There were many interesting differences between groups (too many to mention all), but examples included:
- It was agreed that complexity, coupling, and clones affect understanding, but experienced developers disagreed with inexperienced developers whether size was an important factor.
- Experienced developers were more insistent that smaller classes help testing.
- Inexperienced developers tend to reject large generated classes, but experienced ones accept them.
- Experienced developers prefer absolute metric values rather than the change in the values.
Aside from the keynote, architecture certainly seems to feature heavily this year at CSMR — maybe I have a faulty memory, but it seems to be more so than before. The panel discussion, apparently the first such discussion at CSMR, stimulated some slightly intense debate on the subject of collaborative tool use between academia and industry. It was a shame that we had to cut short, because I do love a good debate. I hope that I see such discussions in future conferences, but I would suggest that it be conducted with a little tighter discipline. Participants were allowed to make slide presentations of arguments and run over allotted time; I’d prefer a format where the chairman presents the arguments and takes a firmer hold of the participants (like the TV programme we have in the UK Question Time).
Looking forward to tomorrow: the software evolution track and the European projects track featuring some meaty FLOSS stuff as well as yet more evolution.
CSMR – Day 1
Guten tag.
How embarrassing. The weather in Kaiserslautern is bad, I’m an Englishman…. and I don’t have an umbrella.
But at least the Fraunhofer IESE Centre is a wonderful environment. Which leads me to quickly express my admiration of the German approach to technical research and development. Briefly, there are four “actors” in their setup: the universities and industry, which scarcely need elaborating on, are two of them. The other two exist in-between these other players. The Max-Planck institutes are outlets of basic research funded mostly by the state. The Fraunhofer institutes are centres of applied science that are mostly funded by contract work. Look them up to learn more.
Onto the conference itself. Today, the keynote was delivered by Dieter Rombach. He argued that when software engineering is being taught, too scientific an approach is taken, and also that people are not sufficiently versed in software engineering principles.
Many maintenance tasks, he argues, are able to be anticipated, and yet they are not prepared for. For example, if you develop software that is dependent upon the CPU, why should you not develop it in a way that makes it as simple as possible to adapt to a new CPU? When developers in the 1960’s and 1970’s developed systems and saved a few bytes by storing the year as two digits, their systems broke when the year 2000 arrived: the shame is, not on them for anticipating it, but on us for not learning from their mistakes.
To prepare for maintenance, Rombach advocates these principles:
- An adroit use of the fundamentals: e.g. divide and conquer, traceability
- Use of software product lines
- Empirically proven best practices
Also worth mentioning is Carola Lilienthal’s paper on analyzing large-scale architectures and suggestions for keeping their complexity under control. Her approach is to compare the intended architecture of the system (e.g. layered architecture) to the actual architecture derived from code analysis. By borrowing from cognitive psychology her paper proposes three aspects for architectural complexity to be applied: modularity, ordering (whether the relationships between elements form a directed, acyclic graph), and pattern conformity. A recommendation is made to begin with a reference architecture and progress to a layered architecture implementing the interfaces as the system grows.
Going to the CSMR Conference
This year’s European Conference on Software Maintenance and Reengineering is in Kaiserslautern, Germany. I’ll be there, but my fellow researchers in the Centre of Research on Open Source Software won’t because we’ve been accepted to so many different conferences we have to divide ourselves up because it’s the only way we can afford to attend them all. So for the benefit of my colleagues (and you, dear reader, if you so wish) I’ll try and find time to blog about the more notable presentations I see there.