Talks

Outreach to other academic and industry is part of my job, the way I see it. Thus I give plenty of of talks. Here's a list of talks in the last three years. I believe my talks are quite entertaining and thought provoking, at least I get that as feedback!

If you're willing to host me (and cover travel expenses :-) ), get in touch!

The ugly little step-brother of glorious source code, documentation is considered a chore by most programmers, and a waste of time by many. However, there is also an annoyingly large number of people that consider it necessary: academic teachers keep pesting us with it, and, more importantly, customers demand it, sometimes. So, why (and when) exactly is documentation a good idea? And how should we document? And how much of it is enough?

In this talk I want to explore what good documentation is, and what kinds there are. And why on earth should we bother in the first place, when everybody and his wife know that the truth is only in the code anyway - right? Slides

Like many other academic disciplines, Software Engineering is a practical craft. Unlike medicine, law, or economics, however, Software Engineering is a fairly recent arrival on the scene. Its development is still explosive, and the impact is only starting to manifest itself in the public eye. We as representatives of this craft have a very special responsibility towards the general public, but first and foremost, it is our responsibility to do our job as best as we can, by the state of the art.

In this talk I want to explore what we - every one of us - can do to live up to this standard, despite pressures on us from all side: impatient clients, economically pressed bosses, and colleagues not all of whom are always helpful. The good news is that it can be done, and that the tools and techniques are widely available to those willing to try. The bad news is that far too often, people get away cheating, cutting corners, and not paying back their (technical) debt. It is not a new story, many of the classic texts have already pointed out the issues decades ago (e.g., Mythical Man-Month, Peopleware, Quality is Free). One might say it is a well known tale of agility and quality. You might also call it the game of code. Slides, Posters, Video

"In God we trust. Everyone else, bring data" says Michael Bloomberg, Mayor of NYC, when it comes to changing policies and procedures in the administration of his town. And right he is: why should New Yorkers accept change and red tape unless there is good reason for it?

In Software Engineering, we tend to accept new tools, techniques, and processes without asking for proof. For instance, in the advocacy for agile methods, where is the data prooving the point? In arguing for model-based software development, what evidence have you seen? All too often, we content ourselves with a gut feeling, a few success stories, the words of a fast-talking consultant, or an enthusiastic article in some glossy magazine or blog. We are craving better solutions for todays problems so much, that we easily fall for anyone promising a magic solution - the infamous "silver-bullet syndrome".

Over the last decade, we have seen a steady increase in the use of empirical methods in Software Engineering research, copying the successful research paradigm of the natural sciences. Clearly, we could benefit from this by increasing the objectivity of our discourses on developing software. Opinions can be turned into hypotheses that may be tested rigorously, to be refuted or confirmed. Over time, thus, opinions turn into facts - or they disappear. Any progress we make this way is true progress that is here to stay, not just a passing fad. The drawback is, of course, that most empirical science is messy, dreary, and slow - there is not much glamour and rock-n-roll in it.

In this talk, I will argue why we need even more empirical research in Software Engineering, how it works in practice, report some of its results, and tell you what's in it for you. This talk has been given in various forms at many venues and in many places.

Slides Video from BigTechDay 6

Models expressed in notations like UML, ARIS, or BPMN are first and foremost media for communication between humans, documenting knowledge about domains or systems. If models are to be more than “black holes” or „write only“, there has to be a way for querying models and extracting information from them. This is a practical challenge, in particular for large and very large domain models: manual search clearly is inadequate, but domain experts are usually not IT experts. Thus, they often lack programming skills to write their ad-hoc queries using an API.

In this talk, I discuss various ways to query models, highlighting their respective restrict-ions. I introduce three experimental model query facilities and present evidence from a series of empirical experiments testing their respective usability. In particular, we show that they outperform OCL in terms of usability.

This talk has been given many times over the past few years, every time with a little update on the latest results. Slides

Many attempts have been made to model GUIs by state machines. None of them have succeeded in getting any industrial traction. I will analyse some of their shortcomings, and present Window/Event Diagrams (WEDs) as a solution to (some of) these shortcomings. WEDs allow sketch input and code generation, and come with a sophisticated tool that offers a whole array of novel features. WEDs are implemented in the Advanced Interaction Design Environment (AIDE), a tool which we have used in half a dozen field experiments to validate the notation and the approach. AIDE offers an array of features for handling model complexity, including well-known ones like support for large-screens, and flexible zooming/panning, but also less well-explored avenues like layered diagrams, and pragmatic sketch-input.

This talk has been given for the first time at the PST mountain cabin retreat 2014, although the topic has been on my agenda since 1999. Slides

Requirements Engineering is well-known to be a critical factor in the success (or failure) of major projects. Any seasoned practitioner has their own, different set of personal experiences of what does and does not work in Requirements Engineering. Or rather: under which circumstances this or that approach seems promising. Based on these experiences we form personal preferences in methods - and many a fast-talking consultant is rather convinced of the medicine they sell. Counter-examples may not get the same attention as success stories. But how can we be sure about the RE methods that we love and believe in? How can we tell hype from innovation? And even more important: what are the right topics and techniques to include in academic teaching?

In this talk, I will briefly discuss the power and limitations of the evidence-based Software Engineering research paradigm that aspires to bring light to this shady business. I shall present some interesting empirical results relevant to RE, and I will present the RED ecosystem, a suite of RE tool specifically geared (but not limited) to academic training.

Any seasoned practitioner has his or her set of personal experiences of what does and does not work in Requirements Engineering, or rather: under which circumstances this or that approach seems promising. Based on these experiences we form personal preferences in methods - and many a fast-talking consultant is rather convinced of the medicine they sell. Counter-examples may not get the same attention as success stories. In particular, if it is convenient in any given hype climate. But how can we be sure about the RE methods that we hope, love, and believe in? And how can we tell hype from innovation?

Evidence-based Software Engineering is a research paradigm aspiring to bring light to this shady business by empirical methods. In this talk, I will briefly discuss the power and limitations of empirical research methods, and present some interesting empirical results relevant to RE.

This talk has been given for the first time in 2014. Slides

Requirements Engineering is widely acknowledged to be the number one factor for the success of projects (or lack thereof, when missing). Yet, neither industry nor academic teaching seem to be very active in improving this sorry state. Being challenged to teach a major RE course at the Master's level at the DTU since 2009, I quickly realized that at least one factor is the lack of a decent, affordable tool; one that employs consistent and academically sound terminology, offers a reasonable coverage of the topics of academic interest and practical relevance, and doesn't take forever to learn - for we only have one term to teach it to students, not a lifetime. Also, it should be free since Universities are notoriously broke, and it should be agnostic as far as methodology is concerned - there are already enough people out there preaching their own method as the one and only. We looked really long and hard, but couldn't find such a tool - so we decided to build our own. This project developed into RED.

RED is a generic Requirements Editor based on Eclipse. It offers a broad range of requirements techniques from RE (goals, textual requirements, stakeholders, use cases), IxD (personas, scenarios, sketches and enactment), and comes with many little useful features, such as group work support, reporting, and table input/editing. RED has been used by hundreds of students since 2011, and runs on all major platforms (though we only really ever test it on Windows).

This talk was first prepared as a tool demo for ECOOP/ECSA/ECMFA 20133 in Montpellier, and has recently been expanded to reflect recent additions to RED and place it in a broader context. See presentation "RE Tools - Academic and Industrial Perspectives".

Poster from ECOOPM/ECSA/ECMFA 2013

Intuitively, it is quite obvious that a diagram with good layout is much easier to understand than a diagram with the same content, but bad layout. However, previous research could not establish this effect. We analysed why this is the case, proposed a new experimental scenario, and conducted a series of experiments where we could actually show that (and how much) layout helps in understanding diagrams. We have studied various influence factors and conclude, that diagram size is among the most important ones. We define notions of diagram size and analyse this influence factor, which leads us to recommendations of optimal diagram size. Recent research uses eye tracking to study the behaviour of modellers when reading diagrams, and informs a theory of diagram reading.

Previous versions of this talk have been given in conjunction with the papers in this thread of research; a summary paper elaborating on these contributions, with new results and a new, improved data analysis is currently in preparation. Slides

Everybody agrees that RE in industry (and academic teaching) is in a sorry state, and in particular, tools are really bad. But why is this so? And what to do about it? We believe, these questions are intricately connected. We present some basics of RE, facts on the state of the art, and a range of tools that facilitate both industrial practice, research, and, in particular, teaching.

Slides

Requirements Engineering (RE) has been identified as a key factor to successful software development, irrespective of the project size, process paradigm, or target industry. However, academic and industrial perspectives differ widely. Industry, on the one hand, is concerned with relatively simply problems but requires polished tool support, ideally with full automation. Academia, on the other hand, is concerned with the most complex problems that exist in highly specialized sub-domains. If tools are created in academia at all, they are research prototypes and usually not solutions to practical problems.

In this talk, we will discuss some issues that highlight the different perspectives. We present RED, a RE tool aspiring to reconcile the academic and industrial perspectives. Created by and for students, it was initially intended as an educational vehicle, doubling up as a validation platform for research results. Given its level of maturity and usability, however, it is rapidly approaching the state of practical applicability.

This talk was given in April 2015 at the SE group in Lund University, Sweden.

Slides / Advertisements in Lund>>>