 Would I need to dive to actually experience a fatal amount of radiation? How long can I stay safely at the surface, and so on? There's some interesting working here. Basically, the kinds of radiation we're talking about, the amount of radiation halves per seven centimeters of water. So actually, you're pretty safe. And you might actually get less radiation exposure sort of just below the surface in the pool outside. And it gets bad if you get really close. So there's that. However, I think the most amusing observation is the one at the end. Just to be sure, I got in touch with a friend of mine who works at a research reactor and asked him, what he thought would happen to you if you tried to swim in their radiation containment pool? In our reactor, you'd dive pretty quickly before reaching the water from gunshot wounds. So think laterally. However, curious enough, that's not the reason I'm here to talk. I'd like to talk about this question, a craftsmanship. What is our motivation for it? What do we mean by it? What perhaps don't we mean by it? What is it antagonistic to? What is it sympathetic with? Just out of interest, just so I know, the degree to which I can reuse things. Who was at my keynote yesterday? OK, I can recycle a few jokes. And a couple of themes. There'll be about two slides that are the same. There's an overlap. But I'll start off with a very similar theme. A few years ago, I co-authored this book, Pattern-Oriented Software Architecture, Volume 5. This book was on patterns and pattern languages, as the title actually suggests. It is very much a theory book. I'd love to say, this is the book you should buy if you're interested in patterns. No, this is the book you read after you've read other books you're interested in patterns. You say, you know, I really want to get inside this idea. I want to know the theory. Frank and I, we kicked this off. Our motivation for writing this was, we keep getting asked the same questions. And we thought, there's no one place that has the answers. And now there is. So it's a response to that. But there's something relevant about the patterns that I'm going to come back to. Relevant about patterns and the ethos of patterns community. I guess this is kind of relevant because Guru Plop is kicking off tomorrow. There were two forwards. One was by Dick Gaver, or the other was by Wayne Kool. Wayne Kool made this observation right at the beginning. Art, craft, engineering, science. These are the swirling muses of design patterns. Art and science are stories. Craft and engineering are actions. It sort of creates this spectrum, where he positions each one of these concepts. And it is a fairly grand claim that in software development we produce art. So one of the themes I'm going to borrow from my keynote yesterday is, as software developers, we do produce art. Installation art. This is Madrid, terminal one. And it's quite a large error message. I had to take two shots to get the whole message. For a lot of people, they're going to be wandering through, kind of ignoring it. A few people are going to look up and wonder, for the non-technical people, the non-technical people are going to focus in because, culturally, we are tuned to do this. We find the word free. Five free packets. Where do I claim my five free packets? I don't know what they are, but if they're free, I'm having them. So this is a nice, large piece of installation art that we accidentally put out there. Now, there's something else that's interesting about this. We can work out what's going on. If when this visualization, when this screen is working, you don't know what operating system it's running. Here, you can tell it's a Linux distro, simply because of the language. I don't know which distro it is, but the language used, it's a Linux distro. So when it fails, we reveal something about the overall structure. We see this as well here, one of my favorite little examples. We get into people's homes and we give them art. This is the Dutch Rail website, NS.nl. Now, I took the screenshot a few years ago. In fact, definitely a few years ago, because this, for me, is many browser generations ago. After Mozilla, I used Firefox, and then I used Chrome. So this is way back. And I was going to see a friend. I was in the Netherlands, and I was going to go see a friend. And I thought, how do I get from Amsterdam to Davenrecht? And so I looked, and I got some times. And I thought, I'm going to see him and his family, and the Dutch eat really early in the evening. So I'm unaccustomed to this. So I thought, I'd better go and see JC a little bit earlier, because last time I turned up, his children were crawling the walls, starving. So I thought, I'll turn up at 5.30, and we'll eat then. So I clicked for an earlier time. Apparently, there is no earlier time. There is only Java dot line dot null pointer exception. Now, this is interesting, because have we not already figured out the technologies involved? I don't understand. Why do people insist on telling you their technology? You don't have to do this, because it says, servler, I can hide all of this. It's like all those pages out there. They've got .php and .sp. It's like the default ringtone on your phone. The first thing you should do to show people that you're not a complete phone idiot is change the default tone. That shows you have mastered your technology. What's funny is that many of the .php, .jsp, and .asp pages out there are not what they claim to be. There's Ruby sites that are replacing PHP sites, but they have to be link compatible. So they're masquerading as .php sites. You don't have to publish all of those lessons about encapsulation. People sort of say, yeah, we do encapsulation, except when it really matters, we tell the world the technology. We reveal everything. But had we not already figured this out, we now know. This failure reveals something about the software. Now, this is interesting, because it also raises questions in our mind. It's kind of practically an article of faith in UI design that you never, ever let the user see a low level error like this. You kind of come back with, I'm sorry, this doesn't seem to be working right now. And you can do that in English. You can do it in Dutch. You just don't do it in Java. And that's kind of, so the question is, how did this get through? What caused or permitted the team to create the software? Now, it is entirely possible they were unaware, a lack of knowledge. But although we regard it as a common piece of knowledge, one of the things we've discovered about common pieces of knowledge is that they are surprisingly uncommon. So maybe they don't know. Maybe we're dealing with new developers who are not connected to a larger culture where this is seen as obvious, and they've not picked that up through immersion and exposure to conversation. So that's a possibility. Maybe it's to do with their testing regime. Maybe this doesn't get through. Maybe it's to do with code reviewing, that this isn't spotted, that people aren't really kind of tuned to that. There's lots of possibilities. So I don't know the answer, but I now have some very good questions. So this is what I'm now equipped with. However, the thing that I find most revealing is that it actually also tells us something about the development process and the organization that surrounds the website. Because I used this slide a few years ago in the Netherlands, about a year and a half to two years after I'd taken the screenshot. And I got the usual laughs. And a guy came up to me afterwards and he said, you know they still have that bug. So now he wasn't originally one of the developers. So what we're saying here is that people across the Netherlands, random people on the street, will know of this bug. Maybe it's valuable. Maybe it's culturally significant to the Dutch people. You can't change the website. This is part of our identity. We like to be tall and we like this bug. But people knew about it and it had not been fixed. We're talking about a really long bug-fix cycle. So what does that tell us about the organization and how it prioritizes and responds to defects? Again, I don't have an exact answer, but I now am equipped with a very particular set of questions that I would like to find out. So it turns out that this kind of in-context failure raises a number of questions that allow us to question and hopefully improve. This is what I didn't take this photograph. This is the Ariane 5 Launcher. It's one of the most powerful and most reliable launchers on the planet. And this is what it looked like on its maiden voyage on the 4th of June 1996, being qualified as Europe's most expensive firework. It scattered parts of the cluster mission over the forests of French Guyana, which I'm sure didn't need the extra pollution. Now, this is a very telling tale because we can actually reveal many things about it. I love this as a worked example because some software failures are either very, very simple or quite tortured and difficult to work through. But just before we explore the details, I want to equip you with appropriate jargon. You don't say the rocket exploded. You say, it experienced a Rudd event. Rapid unscheduled disassembly. You might want to try that next time the server crashes. Did the server just crash? No, it's a Rudd event. And people will not want to admit they have no idea what you're talking about. They're, yeah, yeah, that's what it was. Just try that. So I found it fascinating because the example was very well worked through. There was a study, there was a report on the causes of the failure, came out in late 1996. And I read that. But my interest was peaked recently. A couple of years ago, my co-author, Frank Bushman, sort of said, oh, Kevin, you know about the Ariane thing. And I said, yeah. And he said, yeah, I've got the code. I put it in the slide because he got interested in this. I put it in the slide. And I looked at the code. And I said, that's not the code. He says, how do you know? I said, I can read it. It's too clean. This is the sanitized version of the code. In other words, it's like what happened, but it isn't actually the code. However, relatively recently, so I started trawling the web to see if I could find the original code. And there was a presentation. And there it is. June 96. There it is. There is the code. And there is the offending code down there. Now, the whole presentation is in French, but you don't have to understand French to get a sense of the title. And putty-boog, and grand-boom. You kind of get the gist of what they're talking about. And it works through the issues. Now, so I want to do a quick code review here. Let's see if we can spot some things. First of all, language. Pascal, that's not bad. Warm? No, no. They don't program rockets in Delphi. They program Airbus A320s in Delphi, which worries me. It looks like Fortran, doesn't it? Ada, you're both kind of right. Because it is actually Ada. But it is a sub-dialect of Ada, known as AdaTrend. In the sense that it's not really a dialect of it. It's just what happens when you give Fortran program as an Ada compiler. I was unaware of this term. It doesn't surprise me at all, because I programmed Fortran in two jobs a long time ago. And I remember when I learned C in the first job, I thought I'd mastered it. I thought I knew what I was doing. I was getting it past the compiler, but it was C-Trend. It was C, spoken with a very heavy Fortran accent. And we have the same kind of issue here. AdaTrend. So Linda Rising made me familiar with this term that she has worked in the aerospace industry. Oh yeah, that's AdaTrend. Now, what happens when you give this kind of stuff to Fortran programmers? Well, let's see here. What do you notice about this code? Magic numbers. And they are truly magic in the sense that 32767, I'm glad I'm a geek, because that number means something to me. I played a game of doubling with my 10-year-old the other week. He said, dad, I can double numbers. I said, so can I? I had to do that all the time. And so we did this. And I said, the difference, and eventually it was taking longer and longer to add this stuff. And I said, see, they're hard coded in there. When I'm seeing Ireland and Suffering Dementia, I'll still be able to do the powers of two. I don't remember who I am, but the powers of two will be still in there. So we see 32767. We see minus 32768. Oh, OK. So we're talking about 16-bit side. And of course, because we have Fortran programs, we do not trust the compiler. We do not trust the abstractions that Ada gives us. Ada actually allows you to do stuff like interrogate the type. You can do it as a compile time constant. So a small int, dash, and you can put the property in. I want the max size. I want the min. But because you're a Fortran program, you don't trust that down compiler. You put it in yourself. This is what people mean by heavily typed code. You just type it in. And then you type it in again. Because that way you can be sure it's right. But eventually you'll get bored. And for a bit of fun, you'll put it in hex as well. I mean, why stick to one base? Not only do we have magic numbers, but we decided to flip between bases, either because we're bored or we're trying to show how conversant we are. I mean, I haven't seen the rest of the code. Who knows? There might be base 17 lurking in there. You can go up to base 32 in Ada if I recall correctly. So we've got a lot of repetition. There's a sort of hypnotic trance-like quality to this code. The same kind of structure. Notice the similarity of everything. It's just like, is this an artifact of the Ada language? No, the Ada language is one of the first languages to actually standardize the concept of inline pragmas. I could sit there and say, you know what? We're going to have this is a thresholding piece of logic. If it's above this, threshold it. It's below that, threshold it. Otherwise, use the raw value. So it's a value conversion. Why write that in one line when you can look like you're doing real work, which we know is copy and pasting, and extend it over a larger scope? So what we've got here is an overflow issue. Just out of interest, I want you to use your intuition. What do you think these kind of v, this v might mean? Vertical, yes, because h is horizontal. This is actually components of the horizontal and vertical velocity. We now join the story where I knew about it. What do you think 32 represents? 32 bits, floating point number, all so close. It's actually a 64 bit number. But because we've decided to encode the type in the name, and because this lives within a process where every minor change has to be signed off, no matter how bad the code is, when you realize you wanted a 64 bit, well, we'll just leave the name as it was. So the code is lying to us. And we'll see that all of these values are thresholded, basically. And it turns out that this piece of code is the bit that caused the explosion. Because at 37 seconds into the flight, the horizontal velocity overflowed, the 16-bit boundary. But it wasn't checked. You'll notice there's no guards around it. And at this point, this piece of code went crump. Because in other languages, when you do this kind of conversion, it kind of says, oh, and I'll give you some number. But this is Ada. I'm going to give you an exception. I'm hardcore about this. I'm going to give you an exception. But because we know that this could never, ever happen, never, ever happen in Ariane 4, I'll come back to that. You might notice a diff. This could never happen in Ariane 4. We never put an exception guard. So this part of the guidance system failed, and fed garbage guidance data, and started the rocket spinning. At 39 seconds into flight, the self-destruct mechanism successfully went off. Now, you see, up until this point, I thought that self-destruct mechanisms, that's the stuff of science fiction movies. But actually, no. This is legit. It's installed on rockets. You really don't want a rocket to be going too far in the wrong direction when you've lost control of it. Kill it now. But I do always wonder about that from a job satisfaction point of view. So what code do you write? I write the self-destruct mechanism. How does that work out? Well, hopefully, I've never actually had a call to use it. But we do know that that worked. That was a very profound, whoever wrote that piece of code must have been sitting there going, uh-huh, yeah, that worked. Here's the issue. This is a subtle thing. I just said this was Ariane 4 code. But that rocket which blew up was Ariane 5. Ladies and gentlemen, welcome to reuse. They left the code in Ariane 5. The funny thing is, it wasn't actually needed. All the functionality for that part of the guidance had been taken over by ground control. Had this not overflow, it would have hit the 42nd mark and shut down, and everything would have been plain sailing. But that's the key thing. Ariane 5 is a much more powerful launcher, as I said before. People have this mistaken idea that the purpose of a rocket is to go up. It turns out that space technically starts 100 kilometers up there at the Karman line. It turns out that what you want to be doing is going along really, really fast. It's not up you want. That's 100k. You want to be traveling horizontally 11 kilometers per second. That's non-trivial. So your booster should go horizontal, much faster. And Ariane 5 does this five times faster. It goes horizontal five times faster than Ariane 4. And hence, it overflows. So we have here unquestioned reuse of a component that was never actually required. So next time, by the way, somebody says, I'll leave that code in. We don't need it. It's fine. It's benign. Refer them to this. And the testing and management culture, there's a whole load of stuff that went on there. So yeah, an interesting case study. And we can even start. So some of its management, some of its culture, some of its testing, some of it, we can even start questioning the quality of the code. Because if I had a simple function, threshold this. I'd have been done with all of this in just a few lines. I'd have been able to see that. It would have been trivial. So there's a certain sense of skill. And we want to question here, as well as the larger picture. I use this quote yesterday in my Driven to Test talk. As I said at the time, this is from Kirk Papadine. Functionality is an asset code as a liability. Now, I think this is interesting and provocative for the simple reason that I've maintained the opposite for most of my career. Well, I'm not exactly the opposite. I've maintained the idea that code is an asset. But curiously enough, by phrasing it in this opposite sense, it turns out that it does reveal the fact that we really, really want to care about the code. Because if you have a liability, you watch it like a hawk. You try and make sure you don't have the wrong stuff that gets in your way. What people want is the functionality. If you have lots of dead code, if you have lots of technical debt, if you have lots of issues with the code itself, what you've done is increase the liability. You haven't managed it at all. You haven't controlled it. You've let it run away. You are losing hold of your asset, the asset being the functionality. Your ability to add new functionality is being compromised. So opposite as this initially sounds, it actually tells you why code quality matters. I used this example yesterday as an example of a bit of fun, a bit of art in software. It's called the Clobe, in Suki Endo. Here we see somebody who has had a great deal of fun writing a piece of code. It's OK. You can enjoy this stuff. It's all right. This, when executed, this is Ruby code. It's wrote in 2010. When you execute this, it rotates through 45 degrees. When you execute that, it rotates another 45 degrees. And so on. It's a multi-quine. It's really cool. You can even run it with a specified number of degrees. It does that. This is very, very cool. Now, it doesn't drive rockets. But at the same time, it shows us something else. There is skill involved in coming up with this. There are all kinds of competitions of this kind of thing. It's kind of all the crazy stuff that people occasionally do. And it's OK. I think we need a little bit more fun. But it also shows something you're looking at and going, wow, you sense a greater mastery of code in the Clobe than you do in the Adatran for Ariane 5 or Ariane 4. And yet, this was done with frivolous fun. So clearly, the skills are out. They're just unevenly balanced. When we talk about the idea of software and code, code is art, one of the things that we also want to do is break out of our usual rut. You get used to looking at code in a particular way the same way all the time it becomes. So mind-numbingly familiar that when people do introduce differences, you don't notice them. Sometimes I don't think we appreciate how complex software development is. So can I just get a sense? People who are working on projects, they should involve more than 100,000 lines of code. 100,000 lines of code, that's a lot, isn't it? Anything higher than 500,000? OK, we're going, OK, so we're thresholding. So we're talking about a body of code. Well, let's just rewind a moment. How does that work? How can that work? This is one of the most ridiculously complex things human beings have ever undertaken. The problem is it doesn't look physical. We appreciate things by their physicality. If you've ever stood at the bottom of a very large structure, such as Skyscraper, or a few years ago, I went to the south of Brazil and sort of looked at the Taipu Dam from the bottom. It's a huge dam. Regardless of any environmental impact, you're standing there, and as a small, insignificant human being, you cannot help but feel impressed by this physical structure. And yet, the Taipu Dam is simpler than most large software systems, because it's the same piece as a concrete again and again and again. The calculations were done. They are far simpler than what we were undertaking. This was brought home to me in the late 90s. There was an issue of Scientific American that was focused on mega-engineering projects. And they had three gorges down in China. They had, I think, the bridge across the Orison between Denmark and Sweden. And they had a whole load of others. And they had Windows 2000 development team, which initially seems kind of really funny. And then you realize, you know what? These guys producing the order of 20 to 25 million lines of code individually put together in a way that has to work. It is technically complex. You're talking about a team of a couple hundred people. And they are not laborers. They are all designers. In other words, they are all technically skilled. It's not a handful of engineers plus a bunch of laborers that have been guided. They are all at that elevated level. They are all technically adept. That's really quite challenging. It just doesn't look very impressive when you compare it with large structures that the human senses are tuned to. Oh, yes, damn, very big, very impressive. Code, not so impressive, it fits in the little box. And the boxes get smaller. It doesn't look impressive, and yet it is. A modern, long novel is about 100,000 words. I want you to think about that for a moment. It's 100,000 words placed one after the other using a simple concept called the sentence. It only has to make sense when red from front to back, unless you're getting a bit post-modern. It only has to make sense in one linear execution. That would be fantastic if we wrote code like that. This code is a one-shot. It only does one thing. There's no ifs. But our code is like a choose-your-own-adventure gone crazy. Everything is a branch point. Everything is a decision point. It is one of the hardest things that we do. And we don't appreciate it, which is why it's very difficult to look at code and to extract everything from it. The best we can do in a large system is sample it and surprise ourselves. This is one of the techniques I think is most interesting. It comes from Philippe Calçadeau. He blogged this about three years ago. This idea of take a system, take a code base, strip out the comments, take out the string literals, and put it into a tank cloud generator, used Wordle. And that will show you the frequency of, it will show you the most frequently used words. And we see immediately that this is Java. Import. So there's a lot of language plumbing here. Once you get below the language plumbing, what do we see in the system? String. String is the new int. String is the universal data type. And we see, oh, there are ints. Can we play anything? Yeah, we've got a list. Brilliant. So yeah, I'll come back to that one. It's a little bit. It's missing its domain. It's been compiled into the code. In other words, developers have sat there, and effectively they have built up a mental model of what the system is supposed to do. And they keep that model privately within their heads. They're not sharing that model. Because what they've ended up doing is they have said, it's like this, and you can do that with lists. It's like this, and you can express that in strings. So what they've done is they've already pre-compiled. This is what I call object-oriented assembler. It's probably filled with a lot of get-and-set stuff. It's object-oriented assembler. We have failed to take advantage of a language feature that allows us to express the domain in a way that is comprehensible. I mean, yeah, string's kind of popular. But nonetheless, we have an image problem as it stands. If you go to a party, you casually hang around with people who aren't software developers. You end up with this scenario. What do you do? I'm software development. And you can sense immediately they're looking for the door. They're trying to figure out how to escape. They kind of hold on. There's some little hope in there. There is a possibility that you do something really interesting and cool. Maybe you're actually a games developer. Maybe you've got some funky startup. And so what kind of systems do you produce? I produce systems that have lists of strings. OK, that's it. Conversation over. Come on, we can do better than that. Here's another one. We'll take ourselves and apply the same thing to another system. Now, I can't tell you exactly what this does. But once we get beneath the language plumbing, I'm already getting a sense that the domain is shining through the code. Printing device, picture, product, paper. I'm getting a very different story from this. It does turn out, and you're stutely spotted in the previous one. There you go, car ID. There. There's class, looking kind of small and embarrassed. And then we look around. Class is looking a little happier here. People are defining classes. You know this idea I have? Which idea? You know, like a code. Oh, you can hold that in a string. Yes, but the code itself is not a string. Code has a rule. So the one I often use, I use it as a coding carter, is ISBN validation, ISBN 13, international standard book number, 12 digits, and a 13th digit based on a check sum. And you can also have spaces and dashes in the middle. And it's a really interesting problem, because people try to get all algorithmic, and they kind of break out of any TDD stuff. And now you can do it in a perfectly TDD style. But what is interesting is that a number of people will just do, in a larger problem, are doing a book catalog. They won't just do the ISBN validation. They will generally pass it around as a string, rather than creating an ISBN type. In other words, it's not a string. A string can be used to hold it. But itself, it is not a string. I see this in systems where you end up with a code being passed around, and it gets validated here, and validated again just to be sure. Because you can never trust that code over there. Because it was either written last week, or by somebody else, or you just want to be sure to be sure. Whereas a type provides a constraint, regardless of whether you're dealing with a dynamic or a static language. The purpose of a type is to say, look, this is one of these. It's not anything else. You'll know if it's something else. You can express the concept very directly. So we have this idea of being able to, also, there's a meta-skiller, being able to try and choose unorthodox approaches to looking at your code. This is one of the more interesting ones. There's a whole load of other ones. One of the ones I quite like doing, which I discovered partly by accident, is zooming out. So you can't actually, so all the code is in, like, one or two point font. And, well, you can't read it, then, if it's one or two point font. No, you can't. But it's like flying over a landscape. You see things from the air that you don't see at ground level. You see these vast sweeping structures that repeat across the code. I actually started it when I was looking at some code many years ago. I was scrolling down the screen, and then the screen went white. Because the code was indented outside the window frame. So much indentation. 1,500 line method. It's just like out here. It's just like having that beautiful blank screen. It's elegant in its minimalism, but not, perhaps, that practical. So we have this question of skill and care. And where does that come from? How do we develop such expertise? Now, this is a quote I used the other day, and I want to revisit this one. Because I find it concerning. Christopher Walken, actor, if you want to learn how to build a house, build a house. Don't ask anybody to just build a house. Part of the reason I put it up here is because I remember the Agile Community actually posted this on Twitter to try and make a point about learning. And they were saying, it's a positive thing. You've got to do it yourself. And I said, that's the worst pedagogical advice you could ever offer anybody. Because what you're doing here is, first of all, sure, people have to do stuff themselves. One of the things, if you learn to swim, you can go and read all the pages on Wikipedia. But until you get in the water, you haven't learned to swim. You do have to do something yourself. And there is a way of doing this. First of all, you don't overexpose yourself to too much information. But you take advantage of what other people can offer. Because software development is one of the hardest things we do. We know how to do stuff. To deny yourself that community, that hard-won knowledge, doesn't seem to be particularly practical, particularly with a house. Self-build houses, that seems dangerous, especially if they're anything more than one floor high. And people have a very particular quirky way of doing things. The point that I often make with this is that when people are self-taught, they often become attached to the accidental way they discovered how to do something. Because that's my style. That's how I do this. Oh, yeah, I see other people doing that. But the way I do it is this. Regardless of how dysfunctional it is, they own that. That is part of who they are. You can help them. You can give guidance. You don't just let, you know, it takes a really long time. If you imagine how to build a house incorrectly, list off all the ways, get back to me when you're done. And all the ways to build it correctly, you'll find the second list is much shorter than the first list. There are lots of ways to build structures incorrectly. And there are lots of ways to build code incorrectly and software systems in a way that does not serve the team, the customer, and so on. So it turns out there's more ways of doing things wrong than there are of doing it right. And you can let somebody wander this barren landscape and accidentally, you know, hope that they'll accidentally one day stumble across the perfect technique. But the odds are against them. It's not that it can't happen. It's just it's not likely to. So we want to help people. We have the knowledge. We want them to do stuff themselves. Until they've done it, they haven't done it. But that's not the same as ignore the knowledge that's out there. What happens when people do it themselves? You know this story. Eke Homo. This is in a church in Spain. It was painted in the 1930s. It's not a major, major piece of art. But it's deteriorated over the years. And one little old lady, Cecilia Jimenez, decided she was a local artist in her late 70s. And she decided that she would restore it herself. Now this is one of those things that when you learn and yourself talk, you are particularly susceptible to the Dunning-Kruger effect. Dunning-Kruger effect is where you don't know how bad you are at something. You don't know enough to appreciate that you're not good at something. And this is what she restored it to. It's been variously called Potato Jesus and other things. It is actually now a tourist attraction. People pay to go and see this. The original family of the artist are absolutely up in arms. They want to sue her, whereas she's currently trying to sue the church to get a percentage of the proceeds that they're getting from the people paying to see this. And does this look like code that we have seen? Yes, it does. That's unfortunate, because we have the knowledge to produce stuff like that. Doug Rockford noted in JavaScript the good parts. Programming is difficult business. It should never be undertaken in ignorance. Whilst you have to let people explore a little, you need to give them enough, and you need to be on hand to help. You need to offer certain advice. I'm very, very wary of trying to transfer my own personal interest to my children. I'm very careful of this. But they're kind of getting a little bit interested in programming. We've done some stuff with Python. We used a couple of other tools, Scratch and that. And one of the things that is really interesting is the way to do it is a little bit of guidance, help, and then stand back, let them experiment. One of the reasons I use Python and not Ruby is because Python uses arbitrarily large integers. The first thing I noticed is that when kids are using the command line, when you tell them you can add numbers together and you can multiply numbers, both of my boys independently put really, really large numbers in, like really, really large, like cover four lines, large, and then add it to another number like that. Dad, what's the name of this number? I don't think it has a name, some. Because I'll show you what a Google is, which sounds much more impressive when you tell them it's one followed by 100 zeros. Oh, wow. And then you look at it on the Python screen, and it just gets passed a line, and it doesn't look very impressive. So they want to know the name of the next number up. And yeah, there isn't one. So they experiment in a particular way. So all this brings us to what is hopefully a familiar document, a manifesto, saying we are uncovering better ways of developing software by doing it and helping others do it. Yeah, that value is right in there. We can do this. We know stuff. We're uncovering, and it's a continuous present tense. We are continuing to do so, although it's written 12 years ago. The idea is that this is always going to be true. And the way you get the knowledge out there is by doing it and helping others do it. Now, one of the interesting observations that we encounter that kind of runs counter-attuitive is there's a question. When people, particularly when they get business process consultants involved, of how should we improve our team? And this was forwarded to me, it's the MIT Sloan Management Review. It's forwarded to me by Alan Kelly, because he said there's a really interesting observation here. A large study of over 600 companies with an IT function within them was taken. You can be highly aligned or weakly aligned. And then there is effectiveness. How good is the IT? Not necessarily how good are the developers, but how good are their skills, because it turns out, bizarrely enough, who knew, people learn. But are they given an environment in which they are invited to improve, encouraged to improve? Are they given that environment or not? Now, the good news is exactly as people would expect. Look, highly effective IT, highly aligned with the organization. This is fantastic. IT, the growth that we get from this, great. The expenditure goes down. Most organizations, three-quarters of organizations, are down here in the maintenance zone. Yeah, not particularly aligned, not particularly effective. It turns out that's not as bad as it sounds. Look how close to zero these values are. The problem is when you want to move. A lot of business consultants will tell you, your goal is to become more aligned. And with that, your practices will follow. What happens in reality is disastrous. Your costs go up, and your growth becomes negative. It shrinks. Because what you now have is trying to take a group of people who are not up to matching the pace and the style of the organization and its priority, because they don't think like that. They don't work like that. And they are not necessarily good and effective, in terms of their IT. It now means that they are constantly getting interrupted, constant barrage of problems. And they don't know how to deal with them. Because they're being subject to a very different schedule. And they're not in a position to be able to do that. On the other hand, if you try to improve the practices, whilst perhaps, you know, control the practices, but don't change your relationship to the rest of the organization, of course, you can't run a control experiment like that. Your relationship will change. But if you emphasize the practices, it turns out that you get better. Now, point here, please don't walk away thinking, yeah, we should do the wrong thing better. That's definitely not the take-home message. What we're saying is, be no worse. What we're saying is, as you get good at doing the IT thing, it turns out your ability to respond, whether we're talking about build, test, code, whatever it is, your ability to do this is improving. And when somebody comes back and says, you know what, this isn't quite what we wanted, you can change it easily because you're doing, that's become part of what you can do. You become effective at being able to do that. It becomes easier to take this route than that route. So it turns out that alignment first is actually a dangerous strategy. Whereas you want to emphasize the practices. In other words, you end up with an effective team. You could throw anything at them, and they will respond. If you take an ineffective team and you throw anything at them, then they behave ineffectively on a large scale. You have to learn to be a team. You have to learn skills. And to do so is relatively irresponsible in a lot of organizational environments. Now, it's kind of led to the adoption of not specifically that, but all of these interests ultimately led to a reawakened interest in the craftsmanship idea. Because it was felt after around 2005 approximately that agile had shifted to a space that was less technical, that the majority of the focus of agile work had been triggered. I won't say it started. It has a long prehistory. But the interest in what we recognize as agile was triggered by extreme programming, KBEC's extreme programming. That was the provocative approach that came along. And it was a very polarizing concept. It was very radical. And this whole idea of it was provocative. So people suddenly notice. And then they notice these other approaches that were similar in their ethos, and perhaps a little different in their technical outlook. But that triggered that interest. But following the agile manifesto over the next few years, there was a sense that agile have lost some of its technical grounding. People wanted to reclaim that. So the craftsmanship movement has, in one sense, stepped in there. And the manifesto of software craftsmanship sort of acts as a response. Now, let's just go back. I'm kind of interested in the way that people write things. One of the things I do as a hobby is I write short fiction. So I care very much about words. So I'm very interested in the power of words. And so some key keynotes here, the use of continuous present tense, the collective first person plural, a very clear idea. Through this work, we have come to value. And this sort of simple statement of four values, a simple comparative individuals and interactions over processes and tools, blah, blah, blah. And a clarification. That is, while those value the items on the left, on the right, sorry, we value the items on the left more. And actually, this is a really nice piece of writing. And it's created a lot of follow-ons. I think the Sower manifesto is probably the least effective of more. The problem here is that this is well-meaning words. As aspiring software craftsmen, we are raising the bar of professional software developed by practicing it and helping others learn the craft. Through this work, we have come to value not only working software, but also well-crafted software, not only responding to change, but also steadily adding value, not only individuals and interactions, but also community professionals, not only customer collaboration, but also product partnerships. That is, in pursuit of the items on the left, we have found the items on the right to be indispensable. You can stay awake to the end of that. I don't want to diss the idea, but the presentation is very, very neutral. The manifesto should be slightly more provocative. Really, do I get excited by steadily adding value? Where's the fun? I get excited by other things. Where's the fun? There's the joy. Where's the provocative? Who's saying something really radical here? Nobody's saying, the other one was documentation. You know what? We value software more. Wow, for a lot of organizations, that's a real wake-up call. You can walk in and say, you can observe their activities. And you can see, well, you see you value documentation more than working software, because your whole process is engineered to produce documentation. And we can actually see this. There's actually a litmus test. You can apply to a company at that level. So although it's not a statement to process, it's still surprisingly durable. It's a nice piece of writing. Is this not so much? So let's look at the history of manifestos. So the Marinetti's Futurist Manifesto, 1909, was quite provocative. Futurism is a little bit dodgy in places. And it has a very, very poor view of women. So I'm not going to advocate it, but as its language, it's very, very clear. Because the purpose of a manifesto is to say, guess what? We believe this. If you don't believe that, that's entirely fine. It's not necessarily polemical. Its goal is to say, here's a strong statement of values, just so you're totally clear about what we mean. And we don't couch it in neutral business terminology. So here's a translation. We have been up all night, my friends and I. We've been discussing right up to the limits of logic and sprawling the paper with demented writing. Curiously, I think they were software developers. Our hearts were filled with an immense pride at feeling ourselves standing quite alone. Okay, we have passion. There's passion here. This is interesting. Suddenly you're engaged. You want to know what they're going to say. You want to know if you want to agree with it or disagree with it because they've engaged you. They haven't put you to sleep with business language. We want to sing the love of danger, the habit of energy and rationalism. Whoa, okay. The essential elements of our poetry are courage, audacity and revolt. Wow, okay. These guys are fairly hardcore. But you know that. There's no ambiguity. There's no we're going to synergize with the population and leverage the facilities and society and say, no, there's none of that. It's direct. It's straight out. Artists do this a lot, by the way. I found this book a couple of years ago. That's only a hundred. There's more. Artists do this every few years. So they've been doing it for far longer than the software people. So it starts with Futurists. Here's one that caused a bit of an upset. I think we know which one this one is. Luther, yes. Martin Luther, 16th century, had a few issues with the Catholic church. So he wrote 95 of them up and nailed it to church doors, taking advantage of the new social networking phenomena that was printing. And 95 theses against the church. This clearly caused a bit of an issue. That one also caused a bit of an issue as well. Again, if you read through that, it's just like, okay, we know where you stand. It's very, very clear exactly what they're saying. There's no ambiguity. So I chose this one rather than my own personal copy. I do have copies of all these things because it's the same color as the previous thing. Do we have anything like this in software? Well, here's notes on Postmodern Program. My James and I have a Robert Biddle. 16 bits starting at zero, which I think is very clear too. And zero is manifesto. This is worth a read. For me, this is one of the most important. Although most of the time, I tend to think the word Postmodern is another way of saying crap. We have a Postmodern architecture. You know, actually we couldn't decide what the hell we were doing. It's kind of a bit of a mashup. And who knows what we've got? We've got technical debt. No, it's Postmodern. Oh, okay, that's all right though. So although I take a very, I have a negative outlook on that. In many cases, this is one of the best papers ever written in software development, as far as I can say. And I also saw the live performance of it. Let me think, 2003 at UPSLA. Mary Poppendick went on after James Noble and Robert Biddle who basically did performance art for an hour. And I really felt sorry for Mary because she just stood up there and told us all kinds of really good stuff about lean. But it was a really different. Here's one. Structure like this. We have the left-hand side. We have the right-hand side. And this is very provocative, exciting language. People of Earth, the sky's open to the stars. Clouds roll over us night and day. Oceans rise and fall. We're getting a sense of scale here. Whatever you may have heard, this is our world, our place to be. Whatever you've been told, our flags fly free. Our heart goes on. Forever, people of Earth remember. Wow! Does anybody know the manifesto? It's the Clue Train Manifesto. It was published in the late 1990s. It was 95 theses, based on Luther, 95 theses against business as usual. It was the observations of how consumerism and the ability to buy stuff and also business-to-business interactions was fundamentally changing. Never has shopping online sounded so exciting. I mean, man, these guys took the whole idea, online commerce, and here it is. It's gonna be revolutionary. It's gonna change. And funnily enough, in the heart of this manifesto, in the heart of the published book version of this, there is also a lovely little paragraph that actually comes much closer to capturing the passions and ideals of technical people. People in high tech take pride in their work. There are individuals who see the details of the things they produce and the light of the trials and triumphs they experience while creating products. In the carriage of creation, they find a place to hang their individuality. Programmers and technotypes appreciate elegant spare code and the occasional well-turned architectural hack. It's a beautiful balance. It's exciting. It's passionate. It speaks far more strongly to me than say the craftsmanship manifesto in terms of craft. It does turn out, actually, that we look back, we go back to some of the original XP writings. This is from Ron Jeffries in 1997, 1998. This is before the Extreme Programming White Book came out. And there's a little bit of a change from some of the stuff that Kent says. But he describes simplicity, communication, testing and aggressiveness. Aggressiveness eventually becomes not fearlessness, but courage. There's a very different take on that. But also notice the style of this. This is actually quite a good manifesto. Simplicity, we strive always to do the simplest thing that could possibly work. We're quite serious about this. We have found that with the right architecture and correctly fact code, we can rapidly extend our software when the need arises. Use of the first person plural, collective. You can go through the whole thing and you can agree or disagree, but you know precisely where the XP folks stand. It's a very clear statement. Not simply of values, but of practices. It's just like, okay, and you can choose to agree or disagree, but you know where they stand. There's a no lack of ambiguity and this inspires some people and will repel others. But nonetheless, it's very clear. This is sometimes cited as a kind of key book in the founding of the modern software craftsmanship movement. I'm not so wild about it. I have to admit, Pete McBreen, he wrote this 2001 and I read it. And it's a good manifesto because I disagreed with most of what he said, but I knew precisely where he stood. He, for practical reasons, he caricatures the history of software engineering into something that I don't recognize as the history of software engineering and characterizes, in other words, he sets up sort of straw men to knock down, which kind of, I found a little bit annoying. But he does make a couple of good points. Craftsmanship has been used for centuries for the successful transmittal of skills and the development of communities of practice. He does make this point that there is this notion and this extends out to ideas of apprenticeship. Again, it is worth understanding that there are many professions that follow sort of an idea of an apprenticeship and a mentoring model. My father-in-law is a civil engineer. He does airport, he does airports, runways in particular. In the previous house that I was in, we have the only patio in Bristol that you could actually land a 747 on. I'm pretty sure it's that over-engineered because we got him to help us, and he's sitting there over-engineering and says, I'm sure it's just a patio, but he's sitting there thinking, oh, but why are the plane touches down? Yeah, but it's only a few square meters. He can't get a plane on this, but he can't help it. It's one of the most over-engineered. If the people who moved in after us wanted to get rid of it, they would struggle. They'd have to carpet bomb it to be able to get stuff out. So, there is this idea, but we have to be very careful. When we look at practices of the past centuries, we have to be very careful not to get caught up in certain caricatures. Crasponship movement of the past was based on the guild system. It was a near necessity. And we appreciate that. We have to be very careful not to take it literally. We have to take the lessons learned. Now, do we have a more useful approach to thinking about this stuff? Well, here is back to the Tank Clouds. This is a Tank Cloud created by Olaf Jonsson. It's about three years ago. It was on the software craftsmanship list, and what he asked people to do was to send him three words of what software craftsmanship meant to them. But not to do it on the list. Do it privately, otherwise you prime other people. And he collected this together. And it's really interesting what we end up with. Quality, professionalism, pride, passion, passion. There's passion. Kind of important if you're gonna get excited about something. It's if you wanna do something well, you need to get excited. Care, respect, experience, practice, professionalism, learning, all of these things. We see this going round and round. This is a very good representation. In many ways, it's almost a better representation than many of the other ways we might describe craftsmanship. It's a much better representative. So, an observation of mine, software development can only be considered immature because of how we use our experience, not because we lack it. We actually have, collectively, across all software developers, we know how to do this well. But it's a little bit like the William Gibson quote. William Gibson science fiction author who is basically credited with our current delight in putting words cyber in front of everything. He observes that the future is already here. It's just unevenly distributed. And that way of thinking about it tells us we know this stuff. We just have to try and get other people. How do we create and move that knowledge around? So I think it's time for another manifesto. This was around the time of service-oriented architecture manifesto. And I was running a patents money. I was at a company in Norway and we were basically mining their patents. We were running a fairly intensive workshop going through their systems and discovering their designs and documenting those in patent form. And I seem to remember my response when I sort of showed the, when I was showing this new seller manifesto, having sakes, patents clearly needs one. So pissed off, I went and wrote it out. Patents, we are uncovering better ways of developing software by seeing how others have already done it. That's it. We're done. This is the value. Cause it turns out that we haven't solved everything, but most projects, 90% of any project, wild generalization is standard stuff. You really don't want to get caught in the standard stuff. You want to do the interesting bit, it's different. You don't want to be bogged down in reinventing the wheel and figuring out, should it be blue, should it be red? Should it be round? No, round is an option. Yeah, the wheel's been done. We know the wheel. Let's move on. Let's spread this knowledge. This is an ethos of the patents community. It's not about the gang of four book. It's not about particular books. It's not about particular patents. It's very much this idea. And so, and this actually is the point. This is the very workshop itself. We had a lot of whiteboards available, which was great, because people, if you tell people to write a document, they kind of go into document writing mode and they produce rubbish. Because sadly, software developers are not taught to write. Here you are at a conference on agile development. It's about how we can develop software better. I presume next week you're going to a conference on how to write better, perhaps? No? No? No? Your company's not going to send you an effective writing course? Yeah. It's curious, because sometimes we do this. We sort of say, well, here's the stuff that really matters, and we're going to pay you for it. What's the stuff that really matters? We expect you to write lots. We expect you to present. Okay, and you're going to improve my skills how? We're not. We're just going to assume that you picked up everything you need to know at school. That turns out, I think I'm in my 40s. I think I can finally write, but I'll let you know in another five years' time. I think I've got to the point I can write, but I'm not entirely sure. The point here is that what we have is a lovely environment where people are just thinking, oh, I'm just writing on a whiteboard. I'm just writing on post-its. You de-formalize it. I actually did this with a friend a few years ago. I ran a user group, and I wanted an article, and he had a mental block about writing the article. So he described to me what he wanted to write. So that sounds great. Why don't you just email me what you just said? And I took the email, because you know one thing, software developers are great at writing emails. If you say write me an email, they'll send you thousands upon thousands of words. Let me just tell you about this text in the description. In fact, I'm in the middle of doing it at the moment. I'm writing some code to respond to somebody with an email. Now, have you said, Kevin, could you write some code and do a formal presentation on it, or something like that, or could you put it in a spec? My mindset would be different, but it's just for an email. We will write loads of stuff in an email. So I took what he wrote, turned it into an article. We have to find a way of bringing out that knowledge and getting that flow going. And this happens to be a really good way of doing it. So it turns out that this idea of craftsmanship is entirely understood. I'm gonna let Jason Gorman have the last word on this one. He's based in London. He runs a software craftsmanship conference in the UK. As I said, I'm a little wary sometimes of some of the metaphors used in the software craftsmanship community. I generally consider my area of interest is, I have a set of things I'm interested in. Some of the things I'd like to help people with. A set of things I think can be improved. And if that's what we're calling it this year, I'm all for it. And in five years time, whatever we're calling it, I'm all for that as well. As Jason notes, software craftsmanship is not the next big thing. It's the attempt to articulate what the thing always was. Thank you very much.