 a little bit terrified, but the good excited kind of terrified. Somebody's even decided to come here and see this talk. Although I'm not going to ask why. I mean, did you guys look at the title and think, yes, strong dark pattern development, that's the kind of thing that's relevant to me. I'm guessing that most of you are going to look at the title. And you're probably not really going to tell what this talk's going to be about. I mean, maybe look at the word you think. I don't know, it's just somebody with a duck's driving. Or maybe it's a duck's tithing, I'm not quite sure. One of the way, right, is to move strong ducks, yeah? Well, no, it's not going to be with that. And the title remains kind of confusing, but actually, I don't really want to explain the title quite yet, I want to give a bit of context first. But I'm going to say this is not a talk that's all to do with ducks. So let's start by building a duck. Now, I'm going to say I'm not a professional duck builder. So before I can start to build a duck, I'm going to go out to the question, how do you build a duck? I haven't built ducks before, but I have built other things, other non-duck-related things. And in order to build something, you really need to understand what it is you're building. So the question really becomes, what is a duck? Now, I'm not completely in here. I've got some idea what a duck is. But my past experience suggests that I don't know of them in enough detail. So you can kind of understand the duck in a lot of detail before you build it. Now, again, my experience suggests that I can't hold all that detail on my head in one go. I need to break it down into smaller, more manageable chunks. So I guess the final thing I need to do before I build a duck is to deconstruct a duck, to break it up into these smaller, more manageable chunks. Luckily for me, ducks are pretty common. It's going to be quite easy to find some kind of reference material. So I've chosen this chart. This is a muller. This is a pretty typical duck. I only kind of break this down into the manageable chunks so we can build it up again. Now, I don't build ducks for living, but I do write movies. So I like to think that I understand the important aspects of a duck. I know it's got a wolf-like a duck, and it's got a quack-like a duck. So we can find those bits. We can find a bit of duster quacking, and we can find a bit of duster warping. We cover much of the duck. There's still a whole load of duck left on the conscience board. Now, I know that ducks float, so maybe we've got a floating bit. I know that ducks fly as well, so we've got a flying bit. Now, there's not much detail in there, but it covers enough that duck I'm confident that I can take this and start to reach the shot of the duck. So it's good to go. So we can start with a quacky bit, which I think looks a little bit like that. And then we have the walking bit, which looks a little bit like that, and then the floating bit, and then finally the flying bit. So this is our duck, and it's a pretty rough duck. But this is my first attempt. I mean, we can refine this. Now, one of the things that I know is from looking at this is we have all this negative space. And this wasn't here in the original duck that we looked at. So I'm going to do what any good developer will do at this point. And I'm going to remove the white space, or in this case, the black space. I'm going to get this instead. Now, this is still a pretty rough duck. And the next thing that really strikes me is that all these joints are really jarring. The thing doesn't fit together very well. So when you look at these connections and think, you know, we can improve this, I'm looking at it. I'm thinking, well, everything attaches to the floating bit. So maybe if we change the shape of the floating bit, this will fit together much better. So we can do that. We can put something in place for support of the quacking bit. And then we can put a little support in place for the flying bit. And then finally, we can put something in place for the floating bit. So we'll move up a bit. And this is still a pretty rough duck. But there's nothing obviously wrong with what we've done at the moment, except it doesn't really look like a duck. So I'm going to back to our original source duck, which is this guy. And I'm going to just concentrate on the quacking bit. Now, if we take the quacking bit that we built and superimpose it, we get something that looks like this. And it's not a very good fit. It's just two things, one angle. So we can improve it. And then, yeah, we get something like that. We're just not quite right, but it's a much better approximation. So if we take this and put it back in our original duck, we get this. Now, I've improved the shape of the quacking bit, but overall, our duck is worse. And it's worse because it doesn't really link up properly. Now, I can fix this, obviously. If you look at the floating bit, you can see the angle is warming the snake sticks up too far. And of course, we can just repair that. And it's easy to do, but I'm a little bit uncomfortable as something isn't quite right here. And what happened was I went back to my source and I had changed the quacking bit to be more accurate. And I thought this would make everything better, but this forced me to also change the floating bit. And that's kind of weird. I wasn't trying to change the floating bit. This was forced upon me. This is just really bad coupling for creating it. I'm not going to get too excited about that, but I would bear it in mind as we go on. Look at our duck. I mean, this is still a shit duck, isn't it? So maybe let's look at improving this. And when we last looked, we looked at the quacking bit, and I was thinking, actually, it's all this detail we missed around there. We've got the neck bit, the brain bit, and the eye bits. And these are all missing from our model. So I'm going to go and add them into the model. And that's it. It's not quite right. We need to move the quacking bit, so we'll move it up to there. And now, seeing the fish there, I'm thinking, this is great. We made a bit of progress. This looks more like a duck I did previously. But actually, it's hiding a problem. I mean, we caused some serious damage. And if I hold it floating bit, you can see what the problem is. We have this thing sticking up to the neck. So we built the duck, but it's going to die some slow, horrible lingering death. Now, it's probably not what we want, unless we've got some duck savers here, but we have to ask people to leave, please. Now, we can easily fix this. We can just remove it, okay? Because this is going to be very bad for a duck, so we can just get rid of it. But this is the second time it's happened. We've tried to change something, and then it's poured another change up to us because we've been battling it out. And I think generally what's happening is we're kind of focusing on the bits that we're building as we go along, but we're not thinking about how these bits fit together. And then this is causing problems for us. And this is much more interesting than building the duck. I didn't bring it here today to show you how to build a duck. This isn't a problem that I'm really quite interested in. So I want to start over, but I want to start over by focusing on this kind of problem. So, hello, my name's John, what do we talk? This is about ducks that are driving at ducks that are very muscular obviously. And then let's build a duck. But actually, I'm not going to build a duck again from scratch, I'll get a bit repetitive. Instead, I'll tell you what problem I came across. I work as a contractor in London, and I had a client, and they had previously built a duck, and they called me in to make some changes to it. And they had a piece of code that looked like this. And this is the thing that was responsible for quacking. And it's fine, it works very well, but they were saying no problems, so it was slightly different. We all just wanted to quack. We wanted to quack loudly, and we wanted to quack quietly. I thought, this is a great contract, this is a nice, easy change. So I took the quack method, and that's never going to happen in isolation. I didn't have soft quack, so I just renamed the method to that. The new method for large quack network. And I was about to go and collect my big pilot contract to cash and go home, and I thought, I'm going to see what else is affected by this change. So I run the test suite, and it looked like this. If you haven't seen our script before, I mean, the green dots mean everything is working fine, and then crucially at the end, it says zero failures. I was like, what? This doesn't make any sense. I've gone, I've taken the method out and replaced it with two new methods, but everything is working. So either code is not used in the first place, in which case I can just delete it. The test is wrong. So I did some grep-in, and I found some code that looked a bit like this. Crucially, there's a line in here which calls the old quack method. So the code was in use, which means that the test must have been wrong. It's just a bit of a surprise because this client is very good at white testing. So I had to look at the test and it would be some code and it looked like this. And the problem here is this expect line. So when we write this line, it effectively adds a receiver for that quack method once the object quack in it here. So it changes the interface before we want the code. Now, you can avoid this. In RSpec3, for example, if you use an instance double, it'll raise an exception if you try and do this. My concern is not that we can't avoid this kind of problem. My concern is it's all too easy to have this kind of problem and long notice because if you solve it before, the test's all passed. Around this time, I was playing the go quite a lot and I thought, this is the kind of thing that you can't get on go. So I thought, how are we writing go? So I'm going to show you some go code. Don't worry if you don't know any code. The code should be pretty simple. I'll try and explain it to you along. But I'm going to write the same thing in go. And I'm going to start with the double brain. Now, I'm going to use a struct which is a little bit like declaring a class. And I'm saying it's got a single attribute called quacky bit, which is a type quacker. I'll come back to this type quacker in a moment. But before that, I'm going to add the method on to our dot brain. And we do it like this. And we have to say hello, method on. And all that does is call the quack on the quacky bit. So I'm going to come back to this quacker. Now, because this is go, everything has to be typed. And I've said that type of this is quacker. And because this is go again, I'm going to write quacker as an interface. And we do it like this. And all this says is that we have an interface that's got a single method called quack. It takes more, again, which returns nothing. An interface isn't go, or a little bit like interfaces from Java, or maybe protocols in Clojure, or various other similar constructs in other languages. You can't instantiate an interface directly. What you're doing is saying that something that implements this interface is guaranteed to have these methods inside it. Okay. So this writes an interface. So I'm going to write something called beak. It's a little bit like an empty class here. And I'm going to add a method on to it called quack. And all this does is print a standard line. So there's the mark. Okay. This is pretty much the equivalent of the original Ruby code I showed you. So we can stick it all together now. We can instantiate a new beak object. And then we can instantiate a new dot brain object. And we can set the attribute quacky bit to be as beak. And finally, we can call and say hello on this brain object. And that will call the quack object on the beak. And that will just print quack on the standard line. Or it's very fine. Now I'm going to make the same change to the go code that I made to Ruby code. So we have this beak and we've got a single quack method. I'm going to place it in the soft quack and I'm going to add a new method from my quack. It's actually the same changes we made to Ruby code. Okay. So what happens next? Well, it goes to compile language. So we try and compile it. And it says something a little bit like this. Say you can't make that change. Because we're trying to take beak and pass it into the dot brain and dot brain expects I'm going to type quacker. It'll check beak against the interface quacker and saying we don't need that interface. We're missing a method. We're missing a method here called quack. So in this case I can think, well, the interface is out of date. I need to update the interface to manage the implementation because the implementation is more correct. So we go back to the interface and we just change it to have these two methods inside it. Now I try to compile it, we get a different error. It's nice saying you can't call quack on something of type quacker because that's not in the interface anymore. In fact, if you go back and let it go, you can see we're still calling it old quack method. And that's no longer valid. So I kind of like this. I'm thinking like that the compiler tells me how to break stuff. Now I don't break new log, but I break stuff all the time. And it's really nice that the compiler helped me out and say, hey, you made a mistake. But more than that, the compiler's also hinting about how to fix things. It's not just saying it's broken, you're on your own. It's saying it's broken and you missed its methods. You should have implemented it when you can't call this anymore. There's another nice thing about the Go approach. I was writing duck bread. I wasn't thinking about beak. I wasn't thinking about implementation of anything. And likewise, I was writing beak. I wasn't thinking about bug brain. They're only connected through this interface in the middle. And even better not, the interface is tangible. I can have a look at my code and I can say, oh, look. These are the messages that flew from duck brain to beak between these two objects. So I spoke to a friend of mine. There's a guy called Jacob. He writes Ruby. He also was learning Go at the time. He's a bit of a polyglot. Unfortunately, I've lost exact transcript. It was in Skype. You can never search history in every easily. But the conversation went a little bit like this. And I called him up and said, hey, Jacob, wouldn't it be great with interfaces in Ruby? And he said, in Ruby, this is easy. Just go and write it. And I had to admit it at a point. It is quite easy to go and implement. So I went back to my original duck brain. And I saw, OK, how do we check the type of quacky bit here? My first approach was a bit naive. I wrote some code like this. I said, I'm going to check a response to quack. This is just standard duck typing. And if it doesn't implement that, I thought, OK, I'll raise it an error, in this case, an interface error. And I thought, this is great. Aren't I clever? I just implemented no method error. Except it's less efficient and gives me less information. Probably not the right approach. OK. So I went back and thought about the problem some more. And I thought, OK, really, there are contracts we're putting out between objects. And on one half of the contract, we have an object that promises to provide those methods. And on the other half, we've got an object that promises to only ever use those methods. So inspired by this, I wrote a gem called lawyer, the idea of being that lawyer will enforce these contracts for me. And to write a contract, it's a little bit like writing an interface and go. You write a class inherits from lower gem. And then inside that, you write declarations for the methods you want. So in this case, we'll write a declaration that says, there is going to be a method called quack. And the zero here means it takes no arguments. It's not a method. OK, so how do we use it? When we go back to our quacky bit, all I need to do to say this use of the interface is add a line at the bottom, add a declaration. And it looks like this. And I'm saying, this implements the interface called quacker. OK. So once I make my change again, so if I change quack into soft quack and then add loud quack in, like we did before, what happens is when you load this file, this line at the end gets run, the declaration of implementing the interface. And of course, we don't implement this anymore. So it stops. It raises an exception. It says, you can't do this. Quacky bit does not implement this interface. And then it goes on to tell me why. It says, you're missing a method. And this method is called quack. So this is very similar to the way that go worked. So then we go back to interface. We think, well, actually, the class is right. The interface is wrong here. The contract is wrong here. So we can just change it and add the two methods into there. So now our class loads properly. So that's one half of the contract. What about the other half, the person that's calling it? Well, I can't enforce it in the compiler in Ruby. So I thought, the next best thing for me is going to be RSpec. RSpec is a tool I use a lot to check that things are valid. So I'm going to write a spec which validates this contract for me. So if you write a spec for duckbrain, we had this duck nearby method. So I'll write a spec for that. OK, so inside here, what we're going to do is we're going to call duckbrain, and then we're going to check some behavior. So we're going to call this say hello method. And then we're going to make sure that something has received quack. But I'm not quite sure that something is yet. So I'm going to follow the go approach. I'm going to say, OK, we're going to have something called quacker. And we're going to pass that into duckbrain when we start duckbrain up. And then we're going to check to be called a method in that. So what is this quacket we're passing in? Well, I wrote a helper for this called contract double. It's a little bit like instance double in RSpec 3. What it does is it creates an object. It's got the same interface as anything that implements that contract. So all the methods in the contract will be available in this double object. And it will check method arity as well. So it would say, you need to have the send of arguments. And it checks named arguments as well in Ruby 2. So that's what we create. And we pass it into duckbrain. And then we run our duckbrain code. And then later on, we can say, I want to make sure you call the right methods in this thing that I gave to you. Now, of course, I'm still calling it old interface. I'm calling quack, which we took out of interface. We replaced it with soft quack and loud quack. So what happens when we run this spec? Well, we get a failure, of course, is what you expect. And it's saying, you can't call this. You cannot call quack on this double because it doesn't exist. It doesn't respond to that message. So this is kind of like the go code to me. In the go, I was quite happy because the compiler told me that I broke stuff. I thought that was pretty useful. We don't really have a compiler in a typical sense in Ruby, but I've kind of faked it by saying the tool chain tells me I broke stuff. And this is pretty good. And it's important to note that this is still Ruby and this is still just duck typing. But I've taken it and I've made it strong duck typing. Now, if you go to the internet and you look up the difference between strong typing and weak typing, you're gonna find that it means many different things. It basically means what someone wants it to mean to win an argument. So here's what I think it means to win an argument. Actually, I think it means two things to me. The first thing is that the tool chain is helping to enforce the types. This is not like type annotations where it's up to you to check it. It's not just documentation. It will actually break, tell you early on when you break something, when you have something that doesn't implement the contract properly. The next thing that's important to me is we check before runtime. So duck typing is a really lovely idea, but quite often it manifests itself by running a production and saying, you tried to call this method and it's not there and I'm gonna helpfully crash now until it's all broken. And that's not what I want. I want it to break as early as possible so that we have time to fix things. So we have this thing and then I thought, is it actually useful? And initially I was thinking, yeah, this is great. And I was thinking things like, I've got more confidence that my product, that my code will not break in production. And it's not gonna break because we've got this extra type checking in place. And then I thought about some more. And I thought, well, this kind of interface problem, I've seen it maybe a few times. And I've been writing Ruby for about eight years now. So on average, that's once every couple of years, maybe. And worse than that, I've seen it happen, but it's always been caught really early on. It's very obvious when you make this kind of break, I've never seen this get into production. So I've done all this work, but I've solved a wrong problem. I've solved a problem that doesn't really exist. And I was feeling a little bit down at this point. But it could be worse. I mean, you guys have listened to me for 20 minutes telling you the wrong thing. So anyway, I was a bit down, but then I thought about it some more. And I thought, well, go with doing more than just telling me that it's broken. The other thing it's doing is it's hinting about how to fix things. I thought, that's cool, I've got that as well. You know, it's not just telling me that it's broken, but it's giving me some hints as to how to fix it. That's kind of useful. And then I thought, when I'm writing objects, they don't need to know about each other anymore. They don't need to know about this interface in between. And I also thought, well, interface is tangible again. I can look at my code and I can think, hey, I can look and see a list of messages that are going from one object to another. And this is quite nice. I quite like this. So I want to start over. And I want to bear this in mind. I want to look at how it's changed the way I wrote code. Hello, my name's John, but just talk and duck typing. I want to look at how this drives our code forward now. I want to look at how it changes my coding because this is obviously a picture of me photoshopped a little bit. Okay, so let's build a duck. Now, I want to focus on a little bit of detail here and I want to build, there's quite a lot of code coming up. I want to try and step through it slowly. But I want you to pay attention to the way that I'm being driven forward as I write the code. So we had this bit of duck before and we got the eye here and it's looking around and I thought, well, how is this really going to work? So I imagine the eye is kind of constantly sending image data back and it's going to go to something which is going to interpret the image data. So I'm going to send it to something called the visual cortex. And I was going to do things like shape detection and proximity detection and so on. And then when this thing is a duck nearby, it's going to send a message to the brain. It's going to say, hey brain, there's a duck nearby. And the brain will be responsible for the next part which is probably going to be quacking at it. So it's going to trigger these other processes to make the quack happen. Okay, so I'm going to build some scratch. Now, when I started before with drawing the duck, I could just put the bits of the duck onto the page and that works well when you're drawing stuff but when you're writing code, you can't just put stuff nowhere. We need a container to hold everything together. So I'm going to start by writing a duck class. I'm going to start by writing a spec because I'm a grownup developer. I'm going to start with just one little piece of functionality. So I'm going to say, when we create a duck, I want it to also create a visual cortex for us to use. Okay, so how do we do this? Well, we're going to block of code here which creates a new duck for us. And when we do that, we're going to say, we expect this to also create a visual cortex object. And then crucially, I'm going to say with no arguments and be very precise about what I expect to happen here. Okay, so we run the spec and it failed for a very boring reason because we haven't written any code yet. So I'm going to go and write the duck class. So we start with an empty class. I'm thinking, okay, what do I need to do? What's the smallest amount of work I need to do to make this pass? So I'll write an initializer which creates a visual cortex object. Now, of course, this fails because there's no visual cortex. You get a name error at this point. So test is telling me the next thing to do is go and write visual cortex. Now, if you have a little think about what visual cortex does, it says when is duck nearby, I'm going to tell the brain about this. So I'm going to implement that very small slice of functionality. So let's start running a test for that. So this is a button notifying the brain. I'm missing some context here. I'm going to imagine we set this up so that we are faking the image data coming from the eye which shows a duck nearby. This is the context in which we're running this test. Okay, so how do we do this? So we create a new visual cortex object. I'm going to call it method call run. I've got this kind of idea of just running in a thread on its own constantly processing the image data coming in. And then we'll say, when we run this with a duck nearby and with the right image coming in, they'll make expect it to call the brain and say, hey, there's a duck nearby. Okay, so let's go and write some code for that. We have the test sitting here. So we'll write a run method and it's the smallest amount of work it can do which says, hey, brain, there's a duck nearby. Okay, we have a problem here. I'm referencing brain, but I haven't actually written this yet. It doesn't exist yet. And in fact, we go back to the spec. I did the same thing. I was saying I expect you to call this on brain, but we haven't written brain yet. We have no idea what this thing is. So I'm using some of the trick from before. I'm going to pass something in to the initializer when I create it. I'm going to say, when I create a visual cortex, I'm going to give it an object and I'm going to check that you called something on this object. So what is this thing we're going to pass in? Well, it's a contract double, of course. It's the thing that I used before. And I'm going to create a new contract and I'm going to call this contract greeter because this has to do with greeting nearby ducks. Okay, this spec will not fail because there's no contract greeter. So let's go and have a look at writing that. We write the same as before. We just write a class and the heritage from the lawyer gem. And then we'll put a single declaration there saying you will have a method called duck nearby, which takes no arguments. Okay, so we have our spec working now. We have this thing named and then we pass it into visual cortex. But this fails because we haven't written the initializer in visual cortex to take this argument. So the test is saying you can't do this. You cannot pass an argument here. So we have to go and change that. So we go back to our visual cortex class. We need to add an initializer, which takes an argument. And in fact, this will be a brain that we then try and call later for duck nearby. Okay, at this point when we run the spec for visual cortex, it passes. Everything is great. Except we haven't written the brain yet. So little bit of our code is working. We're quite happy with that. But we still have a chunk to go. And in fact, we're doing it to worry about this because the test is gonna tell us this. If you go back to our duck spec, you can see that we said we're gonna create it and we're gonna create it with no arguments. And this will now fail because visual cortex cannot be created with no arguments as it expects a particular argument to be passed in. And in fact, you get an error like this coming up, which is saying you can't do this. Okay, so what do we do at this point? Well, we said that we're gonna call it with no arguments and we know this is wrong. So what are we gonna call it with? Well, I've written this in such a way that you can just give it the name of a contract. You can say, I want you to call me with anything that implements this particular contract. Okay, so we look at implementing this code. We're gonna say we need to pass something in here, but what's this thing gonna be? We don't have anything to pass at this point. So we need to add another thing. So we go back to our spec. This is saying we already expect to create a visual cortex, but now we need to create another thing as well. So we're gonna say we expect you to create a brain object. And this is the same format. We expect you to create a brain with no arguments. Okay, so now we can go back to our code, the actual code. We can say, right, let's create a new brain and pass it in. Now at this point, of course, the whole thing fails again because we haven't defined brain. So we can do this quickly. We can say, okay, right, a new class called brain, and then we run the spec. And the spec fails because it says you don't match this interface. We expect you to pass something of type contracts greeter into the visual cortex. But the thing that you're passing in doesn't meet that contract. It has no duck nearby method. So this is the thing that we need to go and implement on brain to satisfy the spec. Okay, so we can write a spec for brain. We can say it greets ducks nearby. So we'll create a new brain object. And then we're gonna call duck nearby on it. And then we need to expect some kind of behavior. So here we're gonna expect that we call the quacker and actually generate a quack. Okay, except that we're gonna have quacker yet. So this whole process repeats. We can say, okay, we haven't got a quacker. We're gonna create one. We're gonna pass it into brain. We're gonna create an interface or a contract that specifies what the behavior is from this. And then we're gonna go and find it. When we create the duck object, it's not passing this into brain. And then we're gonna repeat the whole process again and again and again until all of our tests pass. And when the tests pass, we can be pretty confident that we know what's happening. Of course, what we're doing here is letting the tests guide us through this process. It's just TDD, right? This is nothing particularly new. Except that we're adding contracts into the mix. Now this is great for writing new code, but writing new code is easy. I'm not really that interested in writing code. I find that changing code is much, much harder because not only do you have to put in your new functionality, but you need to not break existing stuff. So I think it's really important that we focus on making change easier rather than making writing new stuff easier. So how do we make change easier? Well, we already do this using TDD. We use TDD to make refactoring easier. And in fact, more specifically, I think we use TDD to make refactoring of objects easier. So we can go in and say, I'm gonna change the way this object works. But by adding contracts into the mix, I think we make refactoring of messages easier as well. So when we get our object working the way we want, we can think about the way these objects interact. So we can think about the messages between the different objects. And then if necessary, we can go and change the contract. We can say the way these two things talk is not the way that I expect. And this will generate a load of failing tests. Well, it will if you break something anyway. And then we can go and just fix those things. And then we can be in a nice working situation again and start the process again and think about the messages some more. So look at two types of changes that this supports. One is just changing the message that we're gonna send between objects. So we had this contract before and it defines a single duck nearby methods that takes no arguments. I'm thinking this isn't quite right. I don't wanna take no arguments. I wanna know how close it is. So I'm gonna add a named argument onto there called distance. So I've changed the contract now. So what happens when we run the specs? Well, first of all, you can't even load the classes up because we had this declaration saying that something will already implement this contract. And the fact of breaks, it says you no longer implement the contract. There's a problem. You don't have this named argument in your duck nearby method. And the other side of the equation, if we have something that's using this contract double and trying to call something, we get a different type of failure coming up saying, you can no longer call this method without any arguments. We expect you to pass something in here, something in the name. So we can make these changes to the way two objects speak and we can rely on the specs to come and tell us if there's any implications of that change. The other nice thing we can do is we can swap out implementations very easily. A little caveat here, they need to implement the same interface. So if you've got two things with the same interface, we can change one for the other without breaking any code. So we had this idea of the brain and we talked to the brain and said it's a duck nearby, but actually that's the wrong abstraction. As we develop our system, we might think we're gonna break the brain up into more detailed pieces. I mean, I have something like the frontal lobe being responsible for this high level decision making. So what we do is we make this implement the same interface as something before, as the brain did before. And then we can go back to our duck class, which originally created the brain and passed it to the visual cortex, and we can just replace it with frontal lobe. And assuming these things have got the same interface, they have the same contract, then we can do this and break nothing. And the tests, if they pass, will tell us that this is a fine thing to do. You know, we no problem doing this. And if you don't have the same contract, the tests blow up and say this is not a valid thing to do. So again, we're relying on a test here to tell us what to do next. And what I find is I've learned to trust this. I can trust the tests to tell me what to write next. So what happens is I start in a little isolated pieces of functionality within my system. And I focus on this and I get the test to pass for that particular thing and I start throwing things into this contract to say remind me that I need to write this later. I need to send this message to some other part of the system. So we focus on these little isolated things about thinking about the bigger picture and then we focus on the messages. Now this is probably the most important thing I want to say today, that we start to focus on the messages between parts of the system. So this is a really big idea and it's a really important idea. Now if you look at Alan Kay, Alan Kay was a guy that coined the term object oriented. And then later on he showed a little bit of regret for doing this because in his words, it put the focus too much on objects. And that's not the most important thing. For him, the big idea is messaging. And if you forget everything else I said today, just think, the big idea is messaging. We want to think about not just the bits of system we're building, but how these things talk to each other. Okay, so let's recap. What have we done today? Well, first of all we built a duck and we did it pretty badly. But this is quite interesting because as we built it, we noticed some accidental coupling creeping in. And I said that this is caused by ignoring the connections between objects. And another way of saying that is caused by ignoring the messaging between objects. So that's not where we want to be. So I took duck typing, really standard duck typing, and I supercharged it so that we can focus on the connections between objects. And then we get this to generate errors when we break those connections. But that's not the whole story. What we did next is we took those errors and we used it to drive our development forward. And by approaching coding in this style, we reduced this accidental coupling. I think that this helps avoid ball of mud code. And to me, ball of mud code is the problem I see most often when working in Ruby systems. You get these systems that grow quite large and you can't touch one part of it without that change ripping through and affecting lots of other code. So we fixed this. I think this is a big win for everybody. So this is strong duck type driven development and why I think it's a good idea. Thank you very much for listening.