Mike Sperber

How do we write software that works - or rather, how do we ensure it's correct once it's written? We can just try it out and run it, and see if it works on a few examples. If the program was correct to begin with, that's great - but if it's not, we're going to miss bugs. Bugs that might crash our computer, make it vulnerable to attacks, stop the factory, endanger lives, or "just" leave us unsatisfied. This talk is about techniques every programmer can use to avoid large classes of bugs. You think about general properties of the things in your code, verify them through automatically generated tests, and (when it's particularly critical) proofs. This is a surprisingly fun and satisfying experience, and any programmer can do it. You need just a bit of high school math (which we'll refresh in the talk) to get started.

This talk is specifically about accessible techniques: Almost any program, function, or entity has a few interesting properties, and teasing them out will enhance your understanding of what is going on in your software. The next trick is to write out the property in your programming language. People with lots of time and budget can write down enough properties to form a complete specification of the security- and safety-critical parts of a system and prove that they hold for their system. In the talk, we'll instead focus on a dead-simple technique called QuickCheck. (Your programming language almost certainly has a QuickCheck library you can use.) QuickCheck - from the code describing the property - will automatically generate as many test cases as you want, run them, and produce counterexamples for failures. QuickCheck is amazingly effective at flushing out those corner cases that elude traditional unit tests. Finally, for simple properties of pure functions, we can also attempt a proof using simple algebra. The results are a wonderful feeling of satisfaction, and a sound sleep.

Teaching beginners how to program is often hard. We love building programs, and seeing our loved ones struggle with this is painful. Showing them how to copy-paste a few example programs and change a few parameters is easy, but bridging from there to building substantial programs is a different game entirely. This talk is about how to teach programming successfully, through comprehensible design recipes, which anyone can follow, using languages and tools designed for beginners. This approach is probably different from how you learned how to program, or how you're used to teaching. It is more effective, however, as it teaches more material successfully to a broader spectrum of people. It is also more enjoyable.

The talk is based on many years of research by the Program by Design, DeinProgramm, and Bootstrap educational projects, as well as over 30 years of personal teaching experience in school, university and industrial contexts. A word of warning: The resulting approach is radically different from most teaching approaches used in universities and schools. In particular, it avoids teaching purely through examples and expecting students to develop the skills to arrive at the solutions on their own. Instead, it eaches explicit methodology that enables students to solve problems of surprising complexity on their own, whether they are 11 or 55, whether in a classroom, a training facility, or your home. Extensive documentation, material, and software to support this methodology is available for free.

A major part of software development is maintenance, i.e. tinkering with software that should already be completed but still somehow does not work as it should. Software developed by tinkering is the antithesis to resilient technology, and a growing threat to our profession and our lives. Working on this kind of software crushes the soul. Yet this is exactly how most IoT devices (and computers in general) are programmed these days. We need to replace the dead technology-oriented objects of the past with supple models enriching our domains and our souls. This talk shows how it is done.

So how do we gain autonomy over the software of the future, which is currently spiralling out of control? Not with object-oriented programming, as it turns out: Mutable state, the absence of uniform abstraction mechanisms and the complexity introduced by inheritance make it hard for humans to develop correct and robust software. While "agile" has given developers autonomy over the soul-crushing processes of the past, the prevalent technology - object-orientation - is a fundamental part of the problem, not of the solution. It is time to say goodbye; we must start to teach the principles of systematic construction of correct software instead. At the core of this revolution is the consistent application of functional programming, i.e. of immutable data structures, systematic abstraction and data modelling. The talk illustrates the problems of the programming techniques of the past, and shows how to build robust models that lead to useful software.

Other people: Nicole Rauch

Hacker culture overcomes limitations in computer systems through creativity and tinkering. At the same time, hacker culture has shaped the practice of software development to this day. This is problematic - techniques effective for breaking (into) a computer systems are not necessarily suitable for developing resilient and secure systems. It does not have to be this way: We can approach software development as a methodical, systematic activity rather than tinkering, and teach it accordingly. I'll review my experience teaching these methods for the past 18 years and give some suggestions on what *you* may do.

Hacker culture, which originated CCC (or vice versa?), overcomes limitations in computer systems through creativity and tinkering. Many activities of the hacker community have focussed on discovering weaknesses of IT systems, and creativity and tinkering have been enormously successful at this endeavour. At the same time, hacker culture has shaped the practice of software development to this day. This is problematic - techniques effective for breaking (into) a computer systems are not necessarily suitable for developing resilient and secure systems. The long, long list of vulnerabilities with always the same root causes bears testament to this. Thus, ironically, the very techniques hackers have used to discover and fight vulnerabilities are responsible for them in the first place.

It does not have to be this way: It is possible to construct resilient software systematically, greatly reducing the risk of failure. However, this requires significant changes in culture, methodology, and the tools we use to develop software. We need to approach software development as a methodical, systematic activity rather than tinkering, and teach it accordingly. This will lead to a set of systematic, proven methods that lead to robust and correct software. This talk will introduce available methods, tools, and languages supporting such methodologies: program by design, type-based modelling, mathematics, and functional programming. I'll review my experience teaching these methods for the past 18 years and give some suggestions on what *you* may do.