Category Archives: Uncategorized

Writing a Brilliant Talk Abstract

When giving a talk or submitting a talk to a conference, you are often asked to give an abstract for this talk. This abstract is particularly different from that that you write for a paper for instance. However, it carries some characteristics that are indeed the same.

As I am for the third year in a row in the program committee for the Frankfurter Entwicklertag (Frankfurt Developer Day) – an industry conference – I thought it might be a good idea to provide a small tutorial for producing talk abstracts that lets program committees easily assess the quality of your work and also lets your work shine in the conference programme.

Structure

Having a good structure is key to getting your idea through. If you bore your readers they possibly won’t read until the end. Also if you give all the important information away in the first sentence why should your read bother until the end? So finding the right balance is your task.

A talk abstract is usually larger than a paper abstract. Typical paper abstracts are about 200-250 words. For the Entwicklertag we limit abstracts to 5,000 characters – which is roughly 850 words. You should USE this space… If you just write three sentences it is hard to tell if this is actually great or not.

As Frank Herbert writes in Dune “A beginning is a very delicate time.” The first part of your abstract is there to convince people that it is actually worth reading the whole thing.

Always start with a problem statement. Tell your reader what you are trying to solve or what particular thing you are addressing in your talk.
When your reader has understood what the problem actually is, then you need to convince her that it is actually a problem worth solving. This is the motivation. Tell us why we should care. You can either do this by sketching the benefits of this problem being solved or by outlining the cost of ignoring it.

Now that you caught your readers attention it is the time to actually cash in on it and tell them what you are suggesting in your talk. It is the section where you present your approach to things. Here you can be much more detailed but be sure not to give everything away… Keep them interested to actually listen to your talk, but let the committee know that you know what you’re speaking about. Evidence helps a lot – for instance: GitHub repository? Name it!

Finally it is time to close. It is also the last chance you have to convince the last doubters that your work is great. So first conclude and quickly recap all the things you told us earlier. And then give us some motivation to come to your talk. What do we take home? Will we be a better person? Will be be a better programmer?

Style

A good abstract should stand for its own. It should be self explanatory.  You don’t have to mention every detail of your work, but you have to have every major point that your make in the text.  Be concise and don’t add any fluff… We just want to read about this particular talk and not anything else.

You should be aware of your target audience… Don’t overshoot and rely on things they might not know. But also don’t underestimate what they already know.

Ask yourself while writing: “Would I go to the talk or does the abstract already include everything that I need to know?” Because your ultimate goal should always be getting people to your talk.

Finally…

… all this only works if you have a great thing to talk about in the first place. It is just a way to get your idea across to your readers which you ultimately want to come and enjoy your talk.

What’s so hard about exceptions?

I keep wondering… Why is it actually so hard to handle exceptions correctly?

There are a few ground rules to follow and still people tend to overcatch or throw far too general exception types. As a recent empirical study suggests, this seems to be a general problem throughout software development. There is a brief, very well written guideline for .NET development, I keep waving at my team. I bet there is a similar guide for Java as well – any suggestions?

But I think the problem with exceptions is not just some guidelines that should be followed. Not every developer (and certainly not every customer) is comfortable with the ideal of error that may pop up from out of nowhere. Errors are silently suppressed for the better looks. But missing functionality cannot be hidden. If it doesn’t save, it doesn’t save and I certainly want to know that…

Logging is a way, but there is no path around exceptions in object-oriented programming. Taken that, there is also no way around a fail fast ideology. If something has gone wrong and I cannot do anything about it, it’s best to tell the world and not to brush it under the carpet. That’s also the best way to learn, by the way.

So, the first thing to establish proper exception handling seems to be the introduction of a culture of openly accepted mistakes. “Anything we find now, we won’t find later on.” should be the new motto.

ECOOP 2007 – last day

The day started promising with Jonathan Aldrich’s talk on “Assuring Object-Oriented Architecture”. For me as a software architect, this was the talk of the conference. He was giving a wonderful round trip through the various approaches on assuring architectures. I made loads of notes.

Frankly, the only other talk that really caught my attention on that day was Michael Haupt’s talk on a machine model for AOP. But it was the last day and I was already a little bit “fed up”. Michael’s talk on his and Hans’ work was very inspiring, although I did not understand everything.

In summary, it was good conference that really filled by agenda for the next month and has provided me with some directions for the next years. Which is actually quite nice, because that was the reason why I came in the first place. Another thing: It really encouraged me to find my research area and do a little bit of publication work myself. We’ll see.

ECOOP 2007 – second day

Whoa, this have been some weeks. Sorry about the delay, but my workload was a bit over the top. 🙂

In addition to my last post, I also attended a rather interesting talk given by Mandana Vaziri of IBM Research. About the possibility to declare a notion of object identity beyond the error prone equals/hashCode approach. She has given an insight in the long term goal of querying the heap in the way of a relational database. My mind kept wandering after the talk. It seems like quite a change to the common OO model, but at the same time quite interesting. Much of the current efforts of keeping data objects in data structures would be rendered unneccesary…

On the second day, the Dahl-Nygard Prizes were awarded to Jonathan Aldrich and Luca Cardelli. Cardelli had his talk afterwards about his whole personal history from Simula to C# (He is now at Microsoft Research.).

In the afternoon, I skipped the session on Language Design in favour of a demo session. The first demo was Gael Fraiteur’s demo of PostSharp, a static aspect weaver for .NET. It actually has loads of interesting features and I surely will blog some of my experience with it here. On a side note, it takes quite some guts to travel to a scientific conference such as the ECOOP and talk about the real life features for real life developers the project features, leaving out all to scientific terms not to annoy potential developers. (Especially with Michael Haupt in the audience, grinding his teeth over more than just the overtime Gael took, I think.)

The second demo featured Tours and Traps, a student project from the Hasso-Plattner-Institute, presented by Peter Osburg and Michael Perscheid. It is a system for the planning of tours for a context aware mobile system, which also features traffic information. They implemented it in Smalltalk with Seaside. Each team member was new to Smalltalk, but they managed to deliver working software in a six month time frame without considerable overtime. In the discussion after the talk, we took some time to talk about the role of motivation as a key to project success. Quite inspiring.

ECOOP 2007 – the first day

After a pretty bumpy journey (overbooked flight), I arrived just in time at the ECOOP in Berlin to catch Joe Armstrongs talk on Erlang. In retrospective it really was the right choice, because concurrency seems to be the top theme at the ECOOP this year. It certainly will be a top thing on every agenda for the next five years or so.

I had the chance to talk to Michael Haupt on the role of smalltalk in the future. It seems, I really need to have a look at seaside.

In the afternoon I caught the session on empirical studies hosted by James Noble (in his own way). The first talk was discussing the usage of exceptions in current projects. The numbers are quite alarming, but honestly not very surprising. Proper exception throwing and exception handling are still the major problems in software engineering. I deal with this on a daily basis. The second talk on the influences aspect orientated programming has on software design stability was also quite interesting. In my opinion these studies have to be performed on a wider basis to measure the actual success of language constructs. I was really missing them, when I was writing my diploma thesis.

At the reception in the evening there was a talk by Axel Uhl, the chief development architect of SAP. Although I don’t agree with him on everything, he provided some good insights in actual, real-life software engineering. Especially the notion of software life cycles impressed me.

Let’s see what today has got to offer… It already started pretty good, but more on that later.

Preparing the ECOOP

I’m preparing my attendance on the ECOOP 2007 during the next days.

Quite frankly, I’m a bit nervous. I’m going to be a conference newbie. Well not quite, I’ve been a student volunteer during ECOOP 2003 in Darmstadt, but being a regular attendee will be different. I will only attend the main conference. Hopefully, I’m not missing out on much skipping the workshops.

The conference program looks promising for sure. I will present the most promising talks in the next days.

I hope to get some long term direction from the conference. Choosing the right direction in software architecture is crutial to success, being a (yet) small company. So I hope to get some inspirations from the speaker, as well as from other participants. And of course, the goal to stay in touch with the research community.

In particular, I hope to get a word with Michael Haupt and James Noble, as they have influenced my work in the past.