How to Write a Good Abstract and Title for Presentation at a Conference

Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.
Translation: I would have written a shorter letter, but I did not have the time.
-Blaise Pascal

Writing a good abstract and title for a presentation requires distilling the gist of a complex topic into a few short sentences. Poor abstracts make acceptance of the proposed presentation less likely and discourage potential members of the audience who would benefit. On the other hand, a good abstract and title allow the reader to quickly determine the relevance of the topic and provide confidence that the presentation is well structured, informative, and useful. Anyone who might wish to present at the symposium would benefit from following some simple rules to structure the abstract and title. This document lists some characteristics of good titles and abstracts and provides some practical guidance on how to write a good abstract.

The Abstract
A conference abstract can typically include four sections that answer at least four questions. The sections include Background, Approach, Findings, and Conclusion. At a minimum, answer the questions that correspond to these four sections.
– Background: Why did you do this?
– Approach: What did you do?
– Findings: What did you learn or discover?
– Conclusion: What does it mean?

Here are some questions to consider when you’re drafting your abstract. For each section, select the appropriate questions for your topic, answer them, and then combine the answers to create your abstract.

Background (Why did you do this?)
– What is the problem you are addressing? How are things done today?
– What is the difficulty and why?
– Why has this problem not been solved before?
– What did you expect or what is the hypothesis?

Approach (What did you do?)
– What kind of data did you collect and how did you collect it?
– How did you assess the data?
– Who were the subjects? How many?
– Is this a case study? An experience report? A pilot? Did you set up experiments?

Findings or Results (What did you learn?)
– Did a new technique or approach work or not?
– What new information or data is provided?
– What was confirmed or refuted?
– Were there surprises?

Conclusion (What does this mean?)
– What can we now do differently or that we couldn’t do before?
– Who will be affected by these results? Does this apply to team members? Team leads? Coaches? Other stakeholders?
– Will something be cheaper, faster, or better?

The Title
State your take-home message, or key idea, in a single short sentence. The title should accurately summarize the abstract. The title helps to classify your presentation and set the proper expectations. You may use a title and a short sub-title. It is useful to include important aspects of your presentation in the title. For example, a practical presentation might include “How to”. Similarly a research topic might include “Pilot”, “Case Study”, or or “Survey”. Strive for clarity rather than being clever or provocative.

Advertisements
Posted in Uncategorized | Leave a comment

Quote de jure

“In the absence of clearly-defined goals, we become strangely loyal to performing daily trivia until ultimately we become enslaved by it.”
— Robert Heinlein

Yes, I’ve seen it.

BTW, yes I know the difference between “du jour” and “de jure”, it is is a pun on the latin “concerning law” and the similarly sounding french “of the day”.

Posted in Uncategorized | Tagged , | Leave a comment

Quote(s) du jour

“If you don’t know where you’re going, any road will do” – Watts Humphrey

“Would you tell me which way I ought to go from here?” asked Alice.
“That depends a good deal on where you want to get,” said the Cat.
“I really don’t care where” replied Alice.
“Then it doesn’t much matter which way you go,” said the Cat.
– Lewis Carroll, “Alice’s Adventures in Wonderland”

Plans begin with clarity on the goals. Building on the travel metaphor, you must know “where you are going”.

Next, you must now when you have arrived. The goal must be measurable to the extent that you will know it when you see it. If you have more than a very small number of stakeholders (like more than one), you need this clarity.
The Plan helps to assure that you have the necessary resources, can overcome impediments, and actually measure progress.

A plan does not mean unchanging devotion to the original plan. When conditions change, I change my plan. What do you do?

Posted in Uncategorized | Leave a comment

Don’t reinvent the wheel when you only need to apply some grease.

Process improvement is usually gradual, a series of small improvements that add up to a large improvement. James Watt’s breakthrough innovation of the steam engine doubled the efficiency of the suddenly obsolete Newcomen engine. But subsequent incremental improvements quadrupled the efficiency..

It’s not that hard, but it takes discipline and knowledge. Understanding what to change requires knowledge. You must know the steps in the process, what each step does, and what the results look like. With some modeling one can then foresee the effects of a change. Changing only what needs to be changed requires discipline. Don’t try to do too much at once.

Posted in Uncategorized | Leave a comment

How NOT to identify constraints

I came across a very problematic example of addressing a software development problem using the theory of constraints at http://www.agiledesign.co.uk/2010/theory-of-constraints-for-beginners

So, an example of applying these steps in a software development context might be;

Our goal is to construct, test and deploy software.
Our constraint is in system test, this is apparent due to a build up of software that has not been tested.
We identify exploit opportunities by considering where we loose test capacity e.g. recording timesheets. Since test is the bottleneck, time spent doing administration is directly reducing the output of the system.
We subordinate the system to the bottleneck by changing responsibilities e.g. PM to take on some administrative tasks from testers.

At this stage we return to assessing where the bottleneck is. If we run out of exploit / subordinate opportunities we may choose to elevate the constraint. This is where we consider adding resources, automation or training.

There are several big problems with this.

First, most product approaches insist that the source of the defects be responsible for the the costs, this provides valuable feedback and the right incentives. Shifting to the PM hides the problem.

Second, it assumes that bugs will just happen. This is wrong, they can be prevented or removed earlier in the process.

Third and biggest is assuming that this is a testing problem. It is far more likely a construction problem. Stop sending so many defects into test and you the paperwork won’t be so severe. It is common for 40-50 percent of project effort to be consumed with rework. World class organizations get this to under 5 percent. They don’t do this by having the PM write up the reports or adding testers. They do this by preventing defects or finding them before they get into test.

Posted in Uncategorized | Leave a comment

Alert! Daniel Kahneman’s new book coming soon!

http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374275637/ref=sr_1_1?ie=UTF8&qid=1316387539&sr=8-1

If you were disappointed with “Blink”, this promises to be the book that tells you when to think fast and when to take it slow.

Posted in Uncategorized | Leave a comment

Behavior Trumps Outcomes!

A <a href=”http://www.i2i-align.com/2011/07/why-behaviors-matter-more-than-results.html” blog post over at i2i-align /a> scrateches an old itch.

If we care about results, why not measure by those results?

One answer is that if people have some control over the final numbers, and those numbers are important, they will find ways to hit them, even if it undermines your best intent. Dan Ariely’s narrative about teachers manipulating scores, or worse reminds me of Robert Austin’s warnings about measurement dysfunction. There is also a significant element of Dan Pink’s emphasis on mastery and autonomy, where outcomes based incentives were counter productive to actual production.

For a non-trivial task that requires even rudimentary cognitive skill, creativity, and choice, focus on the process at least as much as the outcome. A good outcome requires a good process. Focus on the process and if it doesn’t give you the results you want, improve that process.

Outcomes can be off for a variety of reasons. But behaviors will get you the outcomes you want more often than not.

Posted in Uncategorized | Leave a comment

Software Architecture, What does it look like?

I am a small part of a project of a project empirically investigating how documented software architecture can positively affect a project. In this case the project is the open source Hadoop distributed files system (HDFS). <a href=”http://blog.sei.cmu.edu/post.cfm/measuring-the-impact-of-explicit-architecture-documentation” title=” Rick Kazman’s SEI Blog Post” > describes some of the background and goals.

I’ve been asked recently “what does a design or architecture document look like?” Well, part of this project was document the architecture for Hadoop, and that document can be found here

<a href=”http://kazman.shidler.hawaii.edu/archdoc.html” title=”Hadoop Architecture Doc” > .

 

Although we often think of Architecture as a high level design, that isn’t really quite right. In design we often have to jumb between high levels of abstraction to more detail, then back again. In short, Architecture tries to capture design aspects most important to satisfying the non functional goals. Some of the description will capture the physical layout of the code modules, e.g. modularity or class structure. Other views may include run time views of data or process flow. Some of the tactics developers might employ could affect architectural properties of the system. They need to have some understanding of those design considerations. That’s the goal of Architecture and architecture documentation.

Posted in Uncategorized | Leave a comment

Quote of the day

“I sell software, not defects”

I was speaking with Isabel Margarido, a Ph.D. candidate, earlier today when she made this remark about her former job in industry. It is a strong statement about personal commitment, quality, and professional engineering responsibility. I’m going to remember and use that line, or some variation, in the future. Customers pay you for the software not the defects, so what do you plan to give them?

Posted in Uncategorized | 1 Comment

Weinberg’s second law

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

 

I came across this again in David Rice’s Geekonomics. Rice also use uses the “bridge” as an example of physical infrastructure that one can see. Software is infrastructure, but it’s not visible. It’s weakness is not readily apparent.

In principle, we could certify software by testing, but by then it’s rather late, it’s already been built. Quality must be built in, that requires real engineering.

Posted in Uncategorized | 5 Comments