This post is from Roman Haas. It focuses on more or less typical problems that appeared to him and his friends during our theses and how to avoid them. They are described by anti-patterns, i.e. there is always a description of a problem and a possible solution for it. The problems are sorted by the moment when… Read More
This post is from Roman Haas. I presented my paper about “Deriving Extract Method Refactoring Suggestions for Long Methods” which I extracted from my bachelor’s thesis as part of the Software Quality Days 2016 conference. This post describes how I ended up at the Software Quality Days, how I prepared my presentation, what I didn’t… Read More
Most good empirical software engineering papers that contain a study follow the same structure for its presentation. As far as I know, this structure was not invented by a single researcher, but developed gradually over the course of many publications. Professional readers expect your case study to follow this structure, too. The audience that really… Read More
A new set of presentation slides is like a program that has never been executed. It probably contains bugs. It reduces the pain for all stakeholders, and most importantly yours, if you test it to discover (and fix) its bugs before exposing it to its audience. My test process for presentations has three steps.
As part of my roles as a PhD student, thesis supervisor and post-doc, I have literally listened to more than five hundred presentations. Unfortunately, many were very bad, making them an uncomfortable experience for both the presenter and the audience. Over the years, I have made it a habit of asking speakers (both of good… Read More
When I listen to a thesis presentation, I need to get the big picture before I care about the details. Until I have understood the problem statement, for example, I do not care how an algorithm works or how its average-case amortized runtime complexity beats existing solutions. Not even if it is presented with a… Read More
The outline is the architecture of your thesis. It decomposes your document into components (called chapters) with dependencies between them (called references). As for software, the architecture plays a crucial role for the success of your project. Read More