 So who am I? Well, I'm an Old Guard Functional Programmer. I got interested in functional programming before my PhD, so that would have been back in about 1974. I've been working with functional languages. All of my career was on the Haskell Design Committee and then about 20 years ago I've been working very hard on something very important. I can't remember what it was now. And I was finished. I had about a week and nothing to do. I thought let's do something fun. And I had worked in the research group in Oxford around Tony Whore, so with a very, very strong emphasis on formal methods in the atmosphere. And I've always liked stating properties of my programmes but proving them. It was hard work then and it's still hard work. So I thought wouldn't it be great if I could just write a property of my programme and then we'll just generate some random stuff. We'll see if I can disprove it. So that's great. So I began hacking on that and I was sitting in my office working away when Coon Klassen knocked on the door and he said hello John, what are you doing? And I showed him this idea and I was approaching it in a wrong headed manner. He went away. Next day he came back with a much better little solution to kind of very early version of Quick Check. And then there were some things he hadn't thought about that I had. So I took that, I worked on it. The following day I went to his office and I had an even better version and we did that for about a week. And at the end of that time we had come up with the first version of Quick Check and the dream that you could just state a property of your code and if it was wrong then you would get a counter example immediately that was fulfilled in a very early form. And it was just so much fun. And I think one of the key things about Quick Check actually is we did it for fun and as a result it is fun and it's fun for other people to use as well. And when technology is fun you know that's a step on the way to adoption right there. So we had this fun and this was about 20 years ago and then maybe six or seven years later I was the leader for a big research project and it was a research project mostly in formal methods and we were called by our funding agency to give a presentation of our work and one of the things we'd done was we'd done some stuff with Quick Check. So we had a quick demo of that and then we talked about all of the other things we were doing. And in the audience there were a number of people, I mean it was an industrial audience, there were some of the influential people at Ericsson and they said well wait a minute go back to that testing stuff. We want that. And so we were quite taken by surprise because we thought it was a small part of the project but we found that the people from industry in the audience got really excited and also in the audience was a woman called Jane Valerud who is one of the top entrepreneurs and startup people in all of Sweden. And she inspired me to start a company and Mike Williams from Ericsson who was one of the designers of Edlang and at that time was responsible for Ericsson's radio base station development, he wanted to be the first customer. So we got started in an ideal situation with a customer who was already excited about our technology and since then yeah that's when we found the company, this was 2006 and I've been continuing to have fun with it ever since. So the question is what is Haskell? What is property-based testing? Let me start off with what is Haskell? So Haskell is a functional programming language. What are they? Functional programming languages in general are languages which are inspired more by mathematical functions than by the architecture of particular of computers. So the architecture of computers has influenced the design of languages like C and if we continue today language like Java are still quite closely tied to the underlying architecture and to give you a way of controlling the machine whereas functional programming languages you might say are more intended to let you describe your problem in a mathematical way and then have the machine solve it for you. So one of the key differences between functional programming and conventional programming is that in conventional programming languages there is always a state which I think it was a big ball of mud and when you call a function you have no idea what it's going to do to the state, what will depend on, what will modify, all of that is invisible whereas when you write a function in a functional language like Haskell then it maps its arguments to its result. It does what it says on the tin. You can see all of the inputs, you can see all of the outputs and when it comes to testing code and figuring out whether or not it's behaving as it should being able to see all of the inputs and outputs just gives you visibility and transparency that makes testing inherently but simpler. Then there's a whole lot of other things in Haskell of course, features that make it very productive to write code in. When I got interested in functional programming in 1974 then people were arguing that it would bring an order of magnitude reduction in the cost of software that is using these languages developers would be an order of magnitude more productive than using the languages of the time. And I think that's largely been delivered. Of course there have been advances in other programming languages too but nevertheless you get a very high level of productivity. It's much harder to shoot yourself in the foot because so many details that you have to worry about in a conventional programming language are taken care of for you in a functional language. So it's simply a very pleasant programming experience. I tend to say nowadays that the reason that I program exclusively in languages like Haskell or Adlang or other functional languages is that life is too short for imperative programming. Imperative programming is like wading through mud. I just don't want to do it anymore. But the other question was what is property based testing? So whenever you write software of any sort you need to test it. And the conventional approach to doing that is you just use it, you supply some input, you look at the output and you ask yourself is that right? And in order to build any kind of confidence in the software you need to run hundreds or thousands or tens of thousands of test cases through it and then check that all of them give the right answer. So of course that's usually automated to some extent nowadays if you look at common industrial practice will be to automate running the program on these thousands of inputs but somebody still has to decide once and for all what the expected output should be. That is a hiding to nowhere as far as I'm concerned. Remember, I'm a lazy person. I don't like to work hard. What I like to do is to state a property of my program. That is another program that will be able to decide for any input. Whether or not the output of the first one is correct. And property based testing fundamentally consists of writing these properties in a form that can be used both to generate test cases and to decide whether or not a test has passed. And then you can build all kinds of intellectual superstructure on top of that basic idea. But basically we're taking software we're running it on generated test cases and then automatically deciding whether or not we should accept the result. When a test fails, we have a counter example that shows that the program is not behaving as it should. Those counter examples are simplified down to the smallest possible counter example and that's a very very good start for debugging. Okay, so what is cubic? Cubic is the company that I founded together with Thomas Arts way back in 2006 after our funding agency had encouraged us to commercialize the property based testing work. And so we started it up with Eric as our first customer. We built a version of our product in airline that was more directed towards Eric's needs. And since then then we've been working in the company with property based testing, applying it helping customers to apply it to a variety of different systems. And of course that's taught us a lot about which extensions you need to be able to apply the basic idea successfully in a wide variety of contexts. So up until IHK, all of our customers used the airline version of the product that we've built at the company. Many of them using it for testing airline code. But we've also worked, for example, with Volvo cars, where the code being tested was real time C code that runs on the processors in cars. So we've tested a wide variety of software, but always with the airline version of the tool. IHK is a Haskell company. And really the first Haskell company that we've worked with. So that's kind of exciting. Especially for me, since I was one of the people, one of the guilty parties responsible for Haskell in the first place. And so now it's a great pleasure to see that it's being used for such an exciting application. And so now we have an opportunity to take the Haskell version of QuickCheck and some of those original property based testing ideas and see how they're being used at IHK. So I think it's always, it's always very interesting to see how ideas that you had, and we're able to try out, you know, in a kind of lab situation, get developed and used when you put them into practice. One of the things we've learned over the years at cubic is that the whole process of scaling up these ideas requires quite a few changes and so on. And there are some dead ends. And our collaboration with IHK really started when IHK asked us to look at the code base and look at the way that Haskell QuickCheck was already being used and identify some, you know, what problems there were in its use. And sure enough, we were able to do that. And so what came out of that was an idea that we would run a training course to improve the use of property based testing at IHK and try and ensure that IHK gets the full benefit out of property based testing and thus hopefully that the product that IHK is able to produce will have a much higher quality than would have been possible otherwise. So that's what it's all about. It's about getting quality software with a reasonable amount of work by applying property based testing to make the whole quality assurance and testing process much more effective. It would be very easy for me as the, you know, one of the two originators of the idea of property based testing to say, Oh, it's vital. It can revolutionize software development. You know, it's the bee's knees. In fact, if you look at most software development, most people aren't using it, even though it's been around for 20 years. So the state of the art in practice, to a large extent, is still you write individual test cases and you run them. However, there are more and more companies that are picking up property based development in one form or another. If you look on the Wikipedia page for quick check, I think there are about 35 something like that ports of the basic idea to different programming languages. So there's a lot of interest in using it. And I part of my vision is to help property based testing become standard practice for software development because I think it has so much to offer. So for example, I myself, I like to use property driven development where I write properties first or at least together with the software that I'm writing. And what I find when I do that is that instead of writing software, which mostly works, and that may be over the coming weeks and months, finally, there are some bugs that I need to go back and fix. I'm able to develop software that perhaps, you know, I have to pause from time to time because quick check shows me that, oh, this idea just doesn't work at all. So sometimes I'll go back to the drawing board early. But by the time I get through that process, I've got software and tests that are so solid that I never have to go back and change the code again, unless I want to add features, of course. But I never suffer bugs in that code afterwards. And we know how how devastating bugs are. I mean, there was a well known report produced 20 years ago for Congress in the US, which estimated the cost of software errors to society as $60 billion a year. $200 a year for every man, woman and child in the US. It's a huge cost. And when you say that people think, well, maybe it's things like, you know, the Ariane five rocket blowing up at launch, but it's not. It's things like word crashing and people losing an hour's work. So there are huge costs in buggy software and property based testing offers a cost effective way of making substantial improvement in the quality of software. It's property based testing is based on property. So it's related to applying formal methods. There's a lot of common ideas that and you can, there's a flow of ideas from one to the other. But we avoid the property based testing. We avoid the proof stage and the proofs are still expensive enough that they can only be used on very, very critical software. Well, what about all of the other software, which also needs to work? There's there's a scope for using lightweight formal methods to bring a sea change and the quality of software that we use. I think that that's that's a vision worth struggling for. This course has been, I think it's been very successful and people seem to be learning a lot about how to apply property based testing ideas, but it's it's not going to be the end of the road. So I'm sure there'll be a role for us to help solve those tricky testing problems that always do tend to come up after a training period. So I hope that we'll be able to work with IOHK on developing property based tests for a key part of the software. People have also been talking to me about areas where they think our help can make a difference. For example, there's compiler testing, testing of the GAC compiler and the new languages that IOHK are developing. And that's something that was close to the research frontier, but because we've been working in this area, of course, we know a lot about it. And so I think it could be very fun to work in that kind of area. But in general, I mean, it's very refreshing to work with a company that has an exciting product developed in Askel and is using all of these ideas, functional programming ideas that I've been involved with throughout my career and now property based testing too. So I'm looking forward to some exciting collaborations in the future.