The Virtue of Simplicity

On January 24, 2025, I was invited to give a commencement speech for the graduates of Passau University. My speech focused on the “virtue of simplicity”, reflecting on the role of simplicity in science, both personal and universal, and how it is important for the future career of graduates.

Dear president, dear mayor, dear graduates, dear families and friends, dear colleagues, dear Gordon, and dear honored guests. What a privilege it is to stand before you on this day.

My name is Andreas Zeller, I am a faculty at the CISPA Helmholtz Center for Information Security in Saarbrücken, on the other side of Germany. 25 years ago, I was a Post-Doc here in Passau, and I invented something very simple that since then, has simplified the life of hundreds of thousands of software developers.

I just used the word “simple” twice in that sentence. There’s a reason for that, and that’s because simplicity is the central topic of my speech. Leonardo da Vinci once said, ‘Simplicity is the ultimate sophistication.’ Today, I want to share why simplicity is a virtue worth embracing as you step into the next chapter of your lives.

Dear graduates: This moment is the result of years of effort, challenges, and growth. You’ve learned to deal with complex schedules, relationships, and expectations. You have learned to navigate between the pitfalls of Java (no, not the island). You have learned to wrestle with Python (no, not the snake). You have dug into the deepest pits of complexity - theory - and you came back to the light, still alive. You first trained and then tamed ML systems and other wild beasts. And finally, you wrote a thesis, which is an incredible feat; and along the way you probably learned how to use LaTeX, which is even more incredible. After 40 years, I still suffer from backslash disease.

When I studied, I have been through the same tests. Granted, we didn’t have Java at the time, but we had Pascal, which is almost as verbose. The first Python release came out just when I had finished studying, so no. But we had complexity theory; we had fuzzy logic as a precursor to ML, and yes, we wrote theses and reports in LaTeX. Except that in my first year of studies, we wer still using punch cards, so you’d write every line on a separate punch card, and then stack them into a batch, and put them into a card reader. (That’s where the term batch processing comes from.) Some 45 minutes later, you’d get the result out, which in many cases would a semicolon too many or a brace too few. And if you slipped on the floor and let your cards fell, you’d have to reorder them all. So I started with punch cards, but after six years, we had high-resolution workstations with windows and mouse pointers and all. That was some quick progress. Also, no internet – except for email and eventually, some FTP servers – but physical books that were always outdated. We have come a long way since then, but the basic problems are still the same: modeling, coding, debugging, understanding software – these were problems back then and are still problems today.

Actually, one might even argue that – at least for software developers – things were much simpler at the time. At the time, you wrote a piece of code that wrote “Hello, world” on the screen. The screen – say, a terminal emulation of 80x25 characters – was yours. You had full control over everything. Hey, you could write a new operating system for your computer if you wanted to. Today, your program prints out “Hello, world” in a terminal emulation on a big colorful screen with plenty of other apps, in 3D, with beautiful user interfaces, shared among users and machines, with cloud storage, maybe with machine learning built in. How insignificant a small “hello, world” must feel on such a screen, only to remind you of all the beautiful things accomplished developers can create, and to remind you of the long long way you still have to go from apprentice to master.

The many apps on your screen, be it at work or on your mobile are a sign of how much of our world today depends on computers. We truly live in the Information Age! Think about your inbox, your social media feeds, your to-do lists – all these things that scream at you for your attention. (Yes, I am talking about you, young man in the back row.) Think about the effort it took to build all this, think about all the components that come into play, and think about all the layers that each have to work perfectly well to form a solid foundation for whatever is built on top of it. The marvels of technology, the marvels of abstraction. Until – well – until it does not work as expected, and that’s when its complexity hits you with all its might.

When software fails, you have to debug it. The word “bug” suggests that this is something that creeps into our code from the outside, something we are not responsible for. But it is our code, it is our mistakes, and it is our bugs. And yet, we have to find and fix them. Debugging is like a crime story in which you are both the detective and the murderer. And debugging can be a long story. We’re not talking about a 30-second spot on TikTok, no, we’re talking about some Netflix epic, say Game of Thrones, ten episodes, one series after another, dozens and dozens of main characters alone. You’re debugging? You better become an expert on who has said what and when and why, and how that resulted in what you see. Debugging may be less bloody than Game of Thrones, but it’s just as unpredictable. Your program gets a NULL pointer, and Ned Stark loses his head. Why, oh why?

In stories, complexity can be entertaining. In your job, it can be paralyzing. What can we do to reduce that complexity? That’s where my story comes in. So, I mentioned that in 1999, I was a Post-Doc, here in Passau. I had done my PhD thesis on models of version control, something that was still new at the time. I had thought: If we have a version history and a test, can we determine the exact moment in time, the exact change that would cause a program to fail? I had developed an algorithm called Delta Debugging that would do precisely that: It would tell you: “Without that change, the program will work. With the change, the program will fail.” So all you had to do is to determine how the change caused the failure and then fix things. Or just undo the change. Which, without looking into what it caused, was a bit risky, of course. I gave the paper the title “Yesterday, my program worked. Today, it does not. Why?”. My advisor hated the title, but let me go with it. That was the day I started off as an independent researcher.

In computer science, we present our work at conferences, and my talk was well received. But after my talk, a guy from industry said to me: “Nice work, but we cannot apply it”. “Let me guess”, I said, “you don’t have automated tests.”. “No, it’s worse. We don’t have version control”. Ah, too bad. I guess I was a few years ahead of my time. But then I thought, if folks don’t have version control, is there something else I can do?

And that brings me to my very simple invention in Passau, in 1999, that has simplified the life of hundreds of thousands of software developers. The thing is: You have a loooong input, a complex input, that you feed into a program – and then the program fails. It turned out that one could repurpose Delta Debugging to simplify that very input into a minimum. Instead of having to figure out what in your 1,000-line LaTeX file causes the problem, it would narrow that down to, say, 5 lines. Instead of 10,000 transactions (and then a failure), it would narrow things down to just two transactions. And since 5 things are easier to comprehend than 10,000 things, it simplified both the inputs as well as the resulting runs, the resulting memory contents, and thus simplified understanding and debugging considerably.

So, how does Delta Debugging work? I think I have been using plenty of computer words in the last minutes, so let me come up with an analogy. Think of your car. At a speed of 80 kilometers per hour, there’s some weird noise coming from the right. What is this? Traditionally, you’d go and search whatever is in your car, maybe riding your car while searching for the source of the noise – ok, having your spouse ride the car while you search for the origin of the noise. That is traditional debugging, the very way that programmers try to find out where a problem comes from.

Delta Debugging is different. The first thing it does is that it takes away half of the parts of your car, say the seats, the doors, the roof, the trunk – whatever. And then it runs your car at 80 km/h, automatically, and it checks if the noise is there or not. If the noise is now gone, then we know it must have been in the parts we just took away. So it takes the other half of the parts and tries to get them to run at 80 km/h. Unfortunately, now, we don’t have an engine, so that doesn’t work. What it then does is to try to take smaller parts away. Maybe just one door at the time. (That may work.) Or just the seats. (That may work, too.) It keeps on taking away one part after the other while the noise persists, until at the very end, all you have left is the engine, four wheels, some fuel in the tank – and the baby rattle that was stuck in the back seat. There you have it: The problem is simplified to the maximum.

It is rather obvious that such a process will always be successful. But in real life, disassembling and reassembling cars is awfully expensive. For inputs, however, this is very easy – it may take no more than a few milliseconds to cut away parts of the input and see if the failure persists. And all of this is done fully automatically. As a developer, you can just sit back and relax while the machine simplifies your inputs – and your life.

Delta Debugging in itself, however, was very simple, too. My Python implementation was less than 20 lines of code. It fit on a slide, and when I presented the approach in 1999, I also showed a slide with my code on it. Now that was a mistake. My talk was again well received, but after the talk, a colleague from France came to me. He was very upset. He said [with French accent]: “Andreas! I would never have sought zat somesing so simple could be accepted at a scientific conférence!” Yep, in terms of intellectual challenge, it was not exactly demanding. But it had actually taken me a year to get it that simple, and since it was simple, it was easy to learn, easy implement, and easy to adapt. It made me quite famous. Just last Monday, our most prestigious scientific journal, Transactions of Software Engineering, had selected the most influential papers of its 50-year history. Gordon Fraser, here present, had one of these, and so did my paper on Delta Debugging. The very paper with the algorithm I wrote here, in Passau am Inn. Und an der Donau. Und an der Ilz.

Now, for me, this was a lesson in simplicity: Do things that are as simple as possible, and do things that make other’s peoples lives simpler. How much time am I on this stage now? Usually, I try to fit things into tweets, just 160 characters. This forces me to stay short and simple. But as I stand between you and your certificates, let me come to an end in simple terms.

Simplicity isn’t about doing less—it’s about doing what matters. It’s choosing depth over breadth, purpose over distraction, and clarity over chaos. When you begin new jobs, pursue advanced studies, or chase big dreams, remember that it is not complexity that equals progress. Sometimes, the simplest solution, the clearest path, and the quietest moment will lead you to your greatest success. You want to be known as “the person who did X”, where X is – well – a simple sentence. You nay less want to be known as “the person who did X — under constraint Y under a full moon unter Berücksichtigung der höheren Lehranstalten”. That’s complexity. Try explaining what you did to your parents, and you’ll find out.

When you build software in the future, always think of: How can I make this simpler? For one, come up with internal designs that are as simpler and as general they can be. Don’t fully ignore performance, but do not performance dominate everything else. “Premature optimization is the root of all evil” – that’s from Donald Knuth, the father of TeX and a grandfather of computer science. Also make things simpler in their usage. Come up with core concepts that are easy to communicate, easy to teach and easy to learn. Allow your users to live in an abstraction, hiding away the many details of what happens underneath.

Because details there are. Behind every abstraction, there are tons of details, and as you work, you will discover that many aspects of life you thought were easy actually are awfully complicated. You think you know how trains work? Planes? Banks? Dig into the details and you will find that there may be a simple abstraction that you learn, say, in elementary school, but behind every such abstraction, there are tons of details for everything in the world that might ever happen. Your job will be to comprehend that complexity, to rule over it, and yet to come up with good abstractions that you can use for your user interfaces, but also to test and verify your software. Trains must not crash. Planes must stay stable. Accounts must be balanced. Friends are to be for life. That’s simple, right? Yet this simplicity is so hard to achieve.

Yet, be wary of those who come up with seemingly “simple” solutions to everything. If someone starts a sentence with “why don’t we just”, be aware that behind pretty much any such a suggestion, there’s again a ton of details which cannot be abstracted away. “Why don’t we just restart our nuclear power plants?” Because that’s actually pretty hairy. “Why don’t we just impose a 90% tax on all the rich?” Because the rich would leave the country, for a start? “Why don’t we just throw all foreigners out of the country?” Well, look around you - such a great pool of talent and promise. We need you. We all need each other. The good news is that often, one simple fact suffices to rebuke an overly simple idea, and it will be your job, too, to counter all these wannabe experts, and carefully explain as the real experts you are why things aren’t always that simple, but you’re happy to work with them on coming up with a simpler solution that actually works.

Simplification that works is something you can and you should strive for in your own life. I challenge you to simplify—not because it’s easy, but because it’s essential. Simplify your priorities, your decisions, and even your definition of success. In doing so, you’ll discover what brings you joy and fulfillment. My hope for you is that you’ll embrace the beauty of simplicity and live a life of meaning.

Congratulations, graduates! The world awaits your brilliance and your simplicity. And you all await your certificates – finally! Thank you very much for having me here and keep on celebrating. You earned it!