KEYNOTE – Code

Transcript

Speaker 1: Now it’s my pleasure to introduce Kevlin Henney, who was our first keynote this morning. Kevlin is an independent consultant and trainer based in the UK, known internationally for his speaking, writing, incidental humor and occasional insights. His software development interests are in patterns, programming, practice and process. Kevlin is a co-author of “A Pattern Language for Distributed Computing.” And, “On Patterns and Pattern Languages,” two volumes in the “Pattern Oriented Software Architecture” series, editor of the “Ninety-Seven Things Every Programmer Should Know,” site and book, and has written many articles and columns both in the treeware form and online. The title of Kevlin’s talk will be “Code,” so please help me in welcoming Kevlin Henney.

Kevlin Henney: Right, morning survivors. Well done. Okay, I’ve been introduced as being from the UK, although I was surprised to discover on arriving here that I’ve been relocated to the United States. You can’t see that there … Which was quite unnerving after nearly 24 hours of travel. What I want to talk about today is code. In fact, I’ve started off very much by using a very simple symbol. If you choose your Twitter tag right, then you never need to introduce your name ever again. Code is kind of everywhere. It has many meanings. What I want to explore this morning is the various meanings of code. I also was to show some source code because I don’t think we get enough source code in keynotes and it’s good to … It’s okay. I won’t ask you to review this stuff. It’s all interesting, and there’s a purpose behind everything.

I want to go further with the meanings of code. Let me think. I’ve already been given a plug for these books, and I will come back to the second and the third one in fact. They are kind of relevant at various points. Other things about me, what else do I do? I have kids, which is one of the reasons I wasn’t able to attend fully this week, and I’ve also been told, because I’m away in August, “Dad, you better bring back something special.” Therefore I’m looking for items that are not made in China, if anybody can recommend anything. I have an interest in amateur photography. Rank amateur, I think, would be the best way of describing it, and writing fiction amongst of other things. This is a whole load of stuff, but the fiction thing is going to turn out to be kind of important here.

Let’s start off. What do we mean by code? I went and culled some definitions from various dictionaries. I have a very strong interest in language and languages, so for some reason, I seem to possess more than one dictionary. Here is the one that we might typically think of, a system of words, figures or symbols used to represent others. A set of instructions for a computer, and a computer program or a portion thereof. This is the stuff that we’re mostly familiar with. There’s a little bit more to it than this. There’s the act of creating code. There is the relationship that we have with code. There’s the way that we think and reason and frame code.

This is from the foreword to “On Patterns and Pattern Language” written by Wayne Cool. “Art, craft, engineering, science. There are the swirling muses of design patterns. Art and science are stories. Craft and engineering are actions. This is a very impassioned way of describing the act of creating software.” It’s very interesting that it connects so many different disciplines and so many different perspectives. Craft is midway between art and science. Art and craft stand over against engineering and science. Art is a unique example, the first thing, the story as artifact condensing out …” and so on and so on. We have this fascinating way of looking at patterns which is a style of presenting and framing stuff we already know. This is the simplest way of putting it. I’m going to come back to that theme a number of times. There are things we know and we need to communicate to others. It’s very important.

Art. I sort of said I’m going to talk about code. Do we have art? Are people who develop software artistic? Well, yeah. Look at that. That’s a work of art. Copenhagen Airport last year. That’s magnificent. That software failure reveals so much. It’s elegant, the coloring is so … It’s such a beautiful shade of blue. It’s practically international [inaudible 00:04:59] blue. The choice of presentation style, this is magnificent. I want to frame this.

I travel through a number of airports, so one of my favorite shots was taken in 2006. This is Madrid Airport. What we’re talking about here is public display of our work, okay? This is fantastic. My youngest son was only a few months old at this time. I kind of did sort of a rugby pass … I would say football, but I really can’t bring myself to do that because that would be handball when you play football correctly. A rugby past. I rugby passed to my wife whilst I got out my camera and took this shot. This is absolutely magnificent. You can kind of spot the geeks because they’re kind of pausing going, “Oh, okay. That’s probably a LINUX distribution because … ” Whereas everybody else is going through going, “Five free packets? Where can I claim them? What are they?” This is a huge error message. I had to take two shots to get the whole thing.

This is our work on display, but it also appears in one of the more common locations. This is another one of my favorites. This is a screenshot. You can tell how old this is because it’s Mozilla. I’ve already gone through two browser generations since this. I can’t remember the last time I used Mozilla. This is a screenshot. I was visiting the Netherlands. NS.NL is the website for the Dutch rail service. I wanted to visit a friend in [Dyvensvek 00:06:42], and so I thought I’d go and look it up, and it gave me a certain time, and I thought, “You know, I’d like to go earlier,” so I pressed the button for earlier, but apparently there is no earlier. There is only java.lang.NullPointerException. I have touched the void, okay? What is interesting here is … There’s multiple things … Is that we have evidence of code in the experience of software. Basically in failure, software reveals itself. We lose all encapsulation.

In failure, a system will reveal not simply the technology. For some bizarre reason, people love to publish their technology. If you hadn’t already figured out it was Java by use of the name Servlet, people love to publish the technology. They talk about encapsulation and then go and publish pages that have got .php or .asp in the name. That’s not encapsulation. You don’t have to name it that way. Here we have a very definite idea that something has happened. It’s Java, but we learn more.

In this moment of failure, we also learn about how the people develop it. We learn something about the developers themselves. One of the common rules is you don’t let exceptions out of the UI, okay? Clearly that wasn’t followed. You put up a message. Say, “I’m sorry, this doesn’t appear to be working right now.” You can do it in English, you can do it in Dutch. Just don’t do it in Java. Clearly that guideline was never … Why was that guideline not followed? Where they not aware of it? Is this a question of knowledge? Is this a question of practice? Is there a lacking review? Are we missing some testing? We learn a little bit about the practices and the culture of the teams. We also learn about the organization.

As I said, this is one of my favorite screenshots, and I used this at a talk in the Netherlands a couple of years ago, and I got the big laugh, and then somebody came up afterwards and they said, “You know, that bug’s still there.” I do not know whether the Dutch people had a great affection for this bug and it had become a national institution. “You can’t fix that.” I don’t think so. They’ve actually revised the website since, but what we’re looking at here is an organization that fails to learn in some way. There’s something about the organization, it’s a known bug. Millions of Dutchmen know about this, yet somehow they’re unable to fix it. “Try Catch. No, that would be too hard.” We learn something here.

This kind of feeds into … It kind of supports at a rather interesting perspective that Kurk Pepperdine, who’s a Java performance specialist and contributor to “Ninety-Seven Things Every Programmer Should Know.” He tweeted this last year. “Functionality is an asset. Code is a liability.” Now, this is interesting. I like it because it’s provocative. Having spent most of my professional career trying to convince people that code is an asset, I’m going to come out against it for some reason. It’s provocative because it makes you think, what is it that people actually want? We want the functionality. The code is a necessary thing, therefore we want as little code as possible to do our job. We want less code and more software. We want functionality. That’s what people invest in, and yet the code becomes a [load start 00:10:07]. It becomes a liability around our necks.

I digress. Let’s go back to the whole thing. Do we have art in software? Do we have art in code? Yeah. Look at that. The IOCCC. Anybody know what the IOCCC is? International Obfuscated C Coding Contest. A magnificent opportunity for people to express their ingenuity and abuse language in a way that people never thought possible. It’s cunning because every year they make sure that there are enough loopholes that can be exploited, and then they close them down the minute something gets in. Just look at this. This is fantastic. Does anybody want to guess what this program does? Calculates pi. Actually, that’s wrong. It calculates E. If you want … Yeah, how perverse is that? We led you this way and we threw you that way. This is humor, this is art. It’s also very clever. I ran it the other day just to check, and yes, it does indeed give you a screen full of E, [inaudible 00:11:22] number. This is really interesting.

This one, the 1989 best layout category. If you actually want to calculate pi, you need this. This is 1988’s best layout category winner. This calculates pi to two decimal places by counting its own area. How geeky is that? Not as geeky as the following, which last year … This is some Ruby code. This is a quine by [Yosuke Ando 00:11:52]. It’s absolutely magnificent. A quine is a program that produces itself, but this does it with a little variation, a little twist. Quite literally, a rotation of 45 degrees. When you execute this, it produces the same thing, but the globe is shifted 45 degrees. Run it again, it rotates more, and so on. You can run it with a number of degrees that you would like it to rotate. This is astonishing. On the guy’s website, somebody actually put, “Do you accept worshipers?”

Now, all of this has a point. What we are doing here, there’s a certain level of playfulness. There is a certain level of joy, but also look at the ingenuity. There is skill and there is focus being brought to attention here. We are really focusing on not just the code but also on the person responsible for the code, and we are admiring it in the kind of sneaking, “Oh yeah, I wouldn’t want to maintain it, but isn’t that really cool?” Kind of way.

Let’s look at something else. Speaking of art, this is one of my favorite little techniques. I picked it up a couple of years ago, and I’ve basically been pushing it ever since to the point that it’s actually now … A couple of people have actually emailed me saying, “I tried this technique. Thank you, very helpful.” Somebody’s actually gone and created a source code cloud generator based on a talk I gave, and I picked this technique out from a blog from Philip Calzado a couple of years ago. How noisy is your code? Take the code, strip out all the comments, throw away the string literals, and put it into a tag cloud generator. He used Wordle. What do you get? Let us reveal, let us see code in a way we have not seen it before. This is fascinating.

What you see below, this is Java. Below the language mechanics, the important public and return, we see string, we see list, we see int, integer. What does this reveal about … Look, we’re in software development, okay? This is not the most exciting profession ever. Sorry. I mean, it’s exciting if you’re in it, but it’s one of those dinner party or cocktail party killer conversations. “So, what do you do?” “I’m in software.” “Oh.” What do they say next? They’ll hold out that maybe you’re into something really sexy like games development. “What do you do?” “Oh, I develop applications that manipulate lists of strings and integers.” Whoa, it was bad enough being software, but now … “Okay, that’s fine. Yeah, I just spot … I just need to make an excuse. Thank you.”

Point here is what we’ve revealed is that the code truly is code. Although the developers who worked on this clearly had a mental model of the universe that they were creating, that knowledge … They had knowledge, but that knowledge has somehow got lost in transliteration. We’ve lost something here. This is all the system reveals to us. When we go back and we maintain it, what are we left with? We’re left with strings and integers and so on. Let’s take another system.

Philip Calzado contrasts this. This is a different system. Beneath the language mechanics, the next level down, what is revealed to us? Printing device, picture, product, paper. The language here is very, very different. In fact, it is the language of the domain. This code is a representation of knowledge. Actually this is what we mean. We have built up a mental model, and here I would like to offer you … This code does not simply modular. It has high modularity and high modelarity. It has high correspondence to a mental model. It’s code we can talk about and communicate with. We’ve learned something very revealing. This whole idea … Try this out on your code base. See what happens. Very, very interesting. Yes, we have art, but the art actually turns into something else. It gives us something more. There is a whole sense of thinking behind this, but there’s more to code than even this.

Code as a word also describes something else. It describes the principles and rules. People talk about a code of practice, they talk about a penal code. We use the word code to describe principles, to communicate values and things like that. This idea of code goes a little bit further. Hopefully this is familiar. If not, you may have walked into the wrong room. This is a code. This is a code that embodies a set of principles and practices. It is still surprisingly fresh and surprisingly original in its form when you actually look at the imitators that came after it, some of which are amusing. I don’t know if you’ve seen the half-assed agile manifesto. That’s quite funny. Some are sadly almost parodies of themselves, like the SOA manifesto, that try too hard to be like this. There’s something very refreshing about this. This is quite an interesting position. It was never intended to be a manifesto, but it became a manifesto in that sense. That gives it some vigor, some freshness.

One of the things that is interesting about it of course is scope creep. We do suffer scope creep. What is the scope creep? The scope creep is something that Jason Gorman who runs the Software Craftsmanship Conference in the UK and he organizes it at Bletchley Park … If we’re talking about code, this is where the code breakers were based in the Second World War. He makes this basis observation. “Anyway, the point I’m making is that we need to be very careful. Just as they’re doing with management consultants, sooner or later our customers will figure out that the management practices of Agile don’t deliver working software any more than they can grill cheese or power an electric bicycle.” There is this notion that we have … Management practices give us the sound of one hand. Without the other, there is something missing. “The business of software is software. We don’t make beanbags, we don’t sell ice cream, even if that’s what will solve the customer’s problems. We make working software, and the manifesto for Agile software development is a manifesto for doing it better.”

That is the original premise. That does not mean that the principles of a gypsy cannot be applied elsewhere. It does not mean that your focus needs to just be within those boundaries, but the manifesto for software for Agile development is very much this specific idea, and it’s important to keep the specifics. Sometimes if we introduce a topic in only the most general terms, people will not be grabbed. You have to be fairly concrete. This is interesting. Jason ended in his typically cervic style. “If you don’t know how to make software, then I’m afraid you’ve boarded the wrong train, my friend. This train is going to better software. The train for management snake oil leaves from a different platform. It’s made of invisible gold, and it runs on magic beans.”

The emphasis here is the focus … Okay, it doesn’t mean that there aren’t other things. There are other things in everybody’s lives, but I thought, if we make it too general, we end up with a wonderful pattern designed to parody this from Joe Bergen many years ago called “Do the Right Thing.” That’s the only guideline you ever need. You don’t need values or principles. You just need one patent, do the right thing. If you do the wrong thing, it’s not right. There we go. That’s it. You’re released. We don’t even need a conference. You just need to do the right thing as opposed to the wrong thing. Clearly we need some specifics. We need to articulate ourselves more clearly. What this is an antidote to is the heavyweight approach, and the idea of the manifestation of code is itself a production concept.

Code is not itself production. We solved the production problem years ago. It’s a design problem. The production problem was solved in 1957. It was called Fortran. It allowed you to instruct a computer as to your wishes and desires using a formal notation that was not at the level of the machine. Then you gave it to another program, and magic happened. It produced running software. That’s amazing. We solved this problem over half a century ago. Everything else is the challenge we’re trying to deal with now. This is a really important observation.

Typing is not the bottleneck, okay? This is a phrase that I used to use in the late 1990s. Typing is not the bottleneck in software development. My frustration at the fact that so many people seemed to target the typing aspect of, “Wow, look. I’ve created a code generator that generates 50,000 lines of code. Isn’t that amazing?” You look at it and go, “Yes, but a good programmer could write that in 300.” “Yeah, but this is enterprise.” That explains it. Typing is not the bottleneck. Any effort … Actually, no. No, I did once work with a programmer for whom it was the bottleneck. In fact, you can tell how far back it is because he used to smoke in the office, and he was a one-finger typist. Most people who claim they’re one-finger typists are not one-finger typists. They’re two-finger typists, one over here and one over here. He was the one-finger typist because the other hand was holding a cigarette. You could always tell the machines he’d been on because there was ash all over them.

For Rod, yes, typing was the bottleneck. For all the rest of us, it is not. This has become a bit of a meme. Sebastian picked up this a while ago and produced this. This is not what coding is about. This is the not the challenge that we face. This is not the issue. My attention to brevity is really a very serious one. Small examples which we’ll see more of later. We have this idea of doing something better.

Now, this is a rather interesting … Oh, it’s a quadrant diagram. We must be from a management magazine, and yes, it’s the “MIT Sloan Management Review.” That’s how you know it’s a management thing, quadrant diagrams, okay? The world is divided into four. It is very simple. There are two axes. Don’t introduce a third one. That will just confuse people, okay? The world is divided into four. There’s normally a happy space and a sad space, or there’s three happy spaces and one sad space or … You know the story.

Now, what is interesting here is that we are looking here at something that challenges a number of things that people do. We have the … This is based on a survey of a number of companies. Alignment with the business and effectiveness of the IT capacity. Software developers and the rest of the IT capacity within an organization, there is this idea of they’re not aligned. You’re in the kind of … Okay, program is not that great, and yeah, we kind of get a few things wrong. We don’t really understand the business. It turns out that you’re actually in steady state. That’s the bottom left hand corner, the maintenance zone. Guess what? Most people are there.

Then there is the happy corner, the IT-enabled right. Look at that. We are highly aligned with the business, and wow, our programmers rock. They are fantastic. We have growth, we have reduced spending. This is brilliant. Now, this is a game, okay? This is a game. You can move one space horizontally or vertically, but you don’t get to move diagonally. That’s two moves, okay? A lot of people move up into the sad, sad corner, the alignment trap. What we’re going to do is we’ll focus … We’ll align with the business because people love the word alignment. It sounds very, very positive. We will align with the business. We can’t develop code for toffee. We’re going to align with the business. It turns out that’s very expensive and surprisingly ineffective. We just become more miserable more expensively. Everybody shares in our misery.

This is the bizarre thing. If we actually focus on how do we produce code better, primarily, looking at it from that point of view. Something very interesting happens. Maybe we weren’t producing the right thing, but we produced the slightly wrong thing better. We’ve produced it more effectively. We can start throwing it away because we know that we can do a better job. We actually get good at … We learn the skills that allow us to move more freely.

One of my other hobbies, I do a little bit of running. I’m currently training for a half marathon. Let’s see how that one goes. Currently up to 10k … No, actually I’m up to 14k, but I’ve run a couple of 10k races. It’s interesting, when I started out about a year ago … How do you run a 10k race? I know, let’s go out and run 10k, 10,000 meters. Yeah, I can run 100 meters. 10,000 meters is just 100 times 100. Yeah, that’s brilliant. I will run it like that. You know what? That doesn’t work. Although it’s aligned with the ultimate goal, it falls so far short of it, it’s unreal. It turns out this is what you have training programs and advice about how to get yourself there. Come the beginning of September, I should be in a position to run a half marathon but not by having tried to run half marathons beforehand. I will learn to become more effective. More effective at all kinds of strange things including getting up in the morning, which has been greatly helped by the jet lag to my advantage.

It turns out there’s a counterintuitive thing. There is a code of practice that says that we should be going vertically, but it’s just like throwing a ball up. It comes straight back down again. What we’re looking for here is something that is kind of responded to with another manifesto. Now, this manifesto was produced collaboratively and with a goal of dovetailing and acting as an addendum to clarify. Although the original manifesto says, “Yeah, we believe the best architectures are going to lead to all of this. We like good code,” but it’s surprisingly lacking in terms of expressing this in proportionate space. Out of the various practices and so on, our principles described, it takes up very little space. This is set to readdress this.

This kind of is a response to Uncle Bob’s fifth Agile value of craftsmanship over crown. However, there is something missing here. I signed this. I went online, put my name to it when it came out, but there’s something missing. Although it dovetails nicely, in that sense is an interesting piece of craft here, “We’re producing not only working software but also well-crafted software. Not only responding to change but steadily adding value. Community professionals, productive partnerships.” There’s something missing here.

This leads me to the next thing that I want to focus on. I was told many years ago when I first visited the US, “Kevlin, yeah, just watch out. If you want to stay on everybody’s good side, things you should avoid talking about, religion, politics, and money.” I’m going to talk about religion, politics, and money. I’m going to talk about money first of all, business value. Lots of people talk about business value. It is the least exciting and most soul-destroying concept I have ever heard of, and I’m quite happy to say that we would like to do is, “And it will result in greater business value,” but business value is not why most people got into this game. If that is what gets you out of bed in the morning, you need a better life, okay? “I’m getting up and I’m pumped about this.” No, I want to solve problems, I want to make people happy. These are all different.

This is not talking about money. This is not about business value. Business value is a way of justifying this stuff. We need to be very careful with the vocabulary. It turns out that actually steadily adding value is not really very exciting. There’s something missing here. The heart is in the right place, but the heart is not pounding strongly enough. What is missing here is passion, is a statement of absolute beliefs.

We’re going to draw your attention to this. This is a manifesto. We need to look at the history of manifestos. I’m going to take you back 100 years or so to Italy, the Futurist Manifesto. Futurist Manifesto, this kind of contrasted, pointed out to me by David Harvey. Felippo Marinetti drafted this one. This is a very interesting thing. It captures a social and an art movement, and the language that is used, “We have been up all night, my friends and I. We have been discussing right up to the limits of logic.” Oh, we’ve done that. “And scrawling the paper with demented writing.” Yep, another story. “Our hearts were filled with an immense pride at feeling ourselves standing quite alone. We want to sing the love of danger, the habit of energy and rashness. The essential elements of our poetry will be courage, audacity and revolt.” They’re not steadily adding value. This is fire. I will admit that the futurists were somewhat aggressive, misogynistic and all kinds of bad stuff, but you knew precisely where they stood. This was not just simply vitreal. This was a structured statement of values. The purpose of a manifesto is not to keep people happy. It’s to let people know what you’re thinking, and then they can figure out whether they want to steer clear of you or not, yeah? It’s supposed to … Otherwise it’s a blog. A manifesto is something different.

This slightly less provocative, but nonetheless a very interesting use of language. “The Style” in the Netherlands, 1989. Europe had been torn apart by war. We have this artistic movement coming out. “There is an old and a new consciousness of time. The old is connected with the individual. The new is connected with the universal. The struggle of the individual against the universe is revealing itself in the World War as well as in the art and so on.” This is really interesting. This is a group of people trying to state their beliefs and their position, and the language is strong. In fact, it turns out artists have been doing this for quite a while.

I’ve picked this book up recently, and yeah, they had to limit themselves to 100, but it’s not just artists. You go back 500 years, religion, Martin Luther. “Ninety-Five Theses Against the Catholic Church.” This triggered the Protestant Reformation. This was a non-trivial event, okay? Ninety-five statements based on reason. “This is where we stand, this is why we do this.”

We also see this … It’s not just religion, it’s not just art. We see it in mathematics. Has anybody come across the Tau Manifesto? Yeah, a bunch of people who think that pi is wrong, okay? Yeah, we saw earlier on that pi produced E, so that was wrong, but that was humorously wrong. That was provocative, classic humor. It causes dissonance. The Tau Manifesto is all about the fact that pi should have been twice its value. We’ll call that tau. That’s the whole point. It’s a statement of beliefs and values, and it structures itself and it says, “Here I am.” It’s not just vitriolic. It’s not just like, “Pi is wrong, that’s it.” No. There’s this structure there. You can be drawn into it, you can work through it, you can respond to it. Yep, there’s a Pi Manifesto now, last updated 4th of July.

Speaking of which, here is very interesting. This is not normally framed as a manifesto, but it is. You can leave all the numbered sections. They’re not very exciting. I want to start with the first statement. This is most famous collectivist statement in the history of the English written language, “We the people.” This is not tame language, nor is this: 1848, London, Communist Manifesto. The connection here is Karl Marx is buried up the road from where I live. I used to walk past the cemetery every day.

I remember coming to the US at the height of the Cold War. Somebody said, “Where do you live?” I said, “Britain.” “Whereabouts” “London.” I thought they’d have heard of that, that was safe. A standard map of Britain for Americans, London and Liverpool is where The Beatles were from, yeah? I hit lucky. He said, “Whereabouts in London?” I said, “North London.” “Oh, whereabouts?” Well, he didn’t know. I said, “Highgate.” He said, “I don’t know where that is.” I said, “Well, I’m buried in the same road that Karl Marx is buried … ” I live in the same road. No, I wasn’t buried there. Not yet. Zombie apocalypse come early. No, “I live in the same road that Karl Marx is buried in.” Now, this is the height of the Cold War. He thinks I’m kidding. If we’d had the web, it would have been a lot of easier to convince him. “Look, there it is.”

This is provocative stuff. There’s some really interesting stuff from this. Yeah, we have the idea of, “Where is the party in opposition that has not been decried as Communist by its opponents in power?” This is 1848, 100 years before McCarthyism. This is interesting stuff. It’s powerful, it’s provocative. You don’t have to agree with it. You just have to understand where it’s coming from. More recently, we see in the domain of computing. Anonymous, the reaction to Wikileaks. Their language is very, very clear. “Anonymous is not an organization or a group of people. Anonymous is decentralized, and as such, it is free.” These are very strong statements of belief, but we can go into programming and find other things.

“Notes on Post-Modern Programming” by James Noble and Robert Biddle. 16 bits started with bit zero manifesto. This is challenging. It turned the idea of messy code into something modern. We don’t have to call messy code messy code anymore. We don’t have to say, “That’s crap.” We can just say, “It’s post-modern.” That’s brilliant. That’s rebranding. Okay, there’s a little bit more to it than that, but nonetheless, I do find it’s interesting. Why use simple short English words like crap or mess when we can use multiple syllables and sound like we’ve picked up an arts education somewhere? “Oh yes, very post-modern.”

We have as well this. Does anybody recognize this? “People of Earth.” “People of Earth, the sky is open to the stars. Clouds roll over us night and day. Oceans rise and fall. 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.” This is the Cluetrain Manifesto. It is a Manifesto about shopping. This is a manifesto about online retail therapy. This is a manifesto about how to buy stuff online. It was present in 95 theses … Sounds familiar … Nailed to the church door of the Fortune 500 websites pretty much. It was provocative because it said, “Business can be different.” Look, this is the most exciting thing you’ve ever likely to read about shopping.

I mean, look at the language in that. It also tells us about ourselves. “People in high tech take pride in their work. They’re individuals who see the details of the things they produce in the light of the trials and triumphs they experience while creating products. In the courage of creation, they find a place to hang their individuality. Programmers and techno types appreciate elegant, spare code and the occasional well-turned architectural hack.” This is magnificent. It starts off about shopping … Okay, fancy word. We call the markets. It somehow sounds more formal. Shopping, okay? I said I was going to talk about money. Here it tells us something about ourselves and the way that we work with this stuff. It tells us about the relationship between those who code and the code, and it’s exciting.

Here’s another one that’s quite exciting predating the Agile Manifesto, predating Kent’s “Extremely Programming Explained.” This is Ron Jeffries’ ex-programming site. This is, as it was in the late ’90s, the four project values. “Simplicity, plus communication, plus testing, equals aggressiveness.” It’s not courage, it’s aggressiveness. If you look at the phrasing, it’s classically manifesto-like. “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 factored code, we can rapidly extend our software when the need arises,” and so on and so on. In fact, if you go and look at the main body of this, I remember looking at it, and it’s written in a dialectic form. I did actually once ask … Right, I think this is the [inaudible 00:36:31] in ’99. It looks like it’s written in Marx’s dialectic. He corrected me quite quickly. He said, “No, a quine is dialectic.” Which I thought was a very good response because they are actually quite similar, but this is language that is colorful.

It turns out, another observation from David Harvey, is that already there was a manifesto for software craftsmanship. It had been sitting around for a couple of years. Pete McBreen’s “Software Craftsmanship: The New Imperative.” This is an interesting book because it’s classically a manifesto, and it’s being a call to action. Most of it is incorrect. It takes an idyllic and rose-tinted view of what craft is or was. Craft was a fairly strange business in the past. It was managed with respect to guilds who were effectively government-extended cartels. The original concept of craftsmanship and guilds was actually disliked by both the economic left and the economic right. You know you’re a loser when Karl Marx and Adam Smith are criticizing it. Nonetheless, it fits everything we know. There’s some good stuff in here. It parodies a few things unintentionally, but it’s strong language. It chooses to take a stand.

This brings us to this point about what is it that we’re looking for. This was … Back to tag clouds, this was a tag cloud generated by [Erlof Bjornsen 00:38:02] on the software craftsmanship list a couple of years ago. He asked people to email him three words that to them meant something about craftsmanship and what it meant to them. This almost stands as its own little manifesto because if we look there, big, quality. We see professionalism, we see pride. Passion is big. Passion, it’s all there. There’s a whole notion here of the importance of this stuff. We’re talking about stuff that goes very much to the sort of center of being a human.

This is taken from James Grenning’s new book, “Test-Driven Development for Embedded C.” There’s a whole load of stuff. I’m going to focus this down, one sentence. “TDD is fun.” Oh, there’s a whole bunch of other reasons, and we could probably even talk about business value, but you know what? The paragraph doesn’t begin with, “Business value, “blah, blah, blah. It begins with fun. “TDD is fun.” In fact, there’s a lot of fun to be had.

Most people here at the conference will have received one of these. What does it say? I thought it was just a drinking container, but actually I’ve been told, according to this, “Congratulations. Here are a few tips to enhance your enjoyment of your new stainless steel drink ware.” It’s not just a container, it’s drink ware. Last night, James gave me this. This counts as a plug for the book I guess, even though I didn’t write it. This is the beer glass to go with the book, yeah? You know how they have tours to go with albums? Yeah, it’s the beer glass to go with the book. On the back, it has, “Hash includes beer.H.” For those of you who don’t drink, just pretend that beer stands for beverage-enhancing encapsulated receptacle. We have there something that is of extreme interest to us.

Here’s another observation. This is from Dick Gabriel. He wrote the book “Patterns of Software.” He also wrote the foreword for one [inaudible 00:40:17] books that I co-authored. He explores another aspect. When we use the metaphor of software architecture, we often talk about software architecture with respect for structure. Again, that’s an architectural concept. We can relate to that. We talk about style. Again, this is classic in all design disciplines. There is a notion of style. This style distinguishes this from this, but we miss one other aspect in the architecture metaphor that makes it somehow a little more human. “Habitability is the characteristic of source code that enables programmers, coders, bug fixers and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.” We’re talking here about comfort.

This is interesting actually because it turns out that we’re not talking … Sometimes people talk about the beauty of code. We’re actually talking about comfort. Comfort and beauty are not necessarily the same thing. Habitability makes a place livable like home. It’s not the same as beauty. It turns out also that most architects don’t deal with necessarily beauty. They deal in functional things that are supposed to be usable and are comfortable. This is what we want in software. If you develop software, you live some of your life in code. Wouldn’t it be nice to make that habitable. Developers feel at home, can place their hands on any item without having to think deeply about where it is. Now, this is very interesting because these are all very human qualities, and yet we have been focusing on talking about code.

Now, let’s talk about quality. This is “Ninety-Seven Things Every Programmer Should Know.” It’s been translated into Japanese. It’s also been translated into Czech, but the reason I’ve got the Japanese up there is because this is how all printed books should be done. The quality, the print quality is magnificent. The feel of the book … If all paperback books were produced like this, it would just be amazing. This is a treasured item. I almost want a second copy of this, but I’ll translate something back into English that I wrote in the preface. “There is an art, craft and science to programming that extends far beyond the program. The act of programming marries the discrete world of computers with the fluid world of human affairs.”

What we’re talking about here is this rather interesting thing that the developers exist in this rather strange space. They are surrounded by the code of business, the code of practice. These are fluid. We are mediating between the negotiated and uncertain truths of business and the rest of the human world and the crisp, uncompromising domain of bits and bytes and higher constructed types. What we are looking at here is a relationship between one set of code and another, code that is unforgivingly binary and black and white and boolean.

There he is, the man, George Bull, who formalized propositional calculus and gave the name boolean logic, but there is a deep, deep irony. The book is entitled “An Investigation of the Laws of Thought on Which are Founded the Mathematical Theories of Logic and Probabilities.” This is deeply ironic because this is the biggest problem that we have. We are not logical. We are human beings. I know, this is news. Software developers are human too. I know. You have to go out and look for the evidence, but no, it’s true. Absolutely astonishing. Who knew? It turns out that the greatest challenge people have is negotiating these two disciplines. These are two worlds. How well suited are we to it? How rational are human beings?

This is a rather good book by Gary Marcus. I was going to give a talk on this a couple years ago. “Kluge: The Haphazard Evolution of the Human Mind.” Kluge, sometimes pronounced “kludge,” a solution that is clumsy or inelegant yet surprisingly effective. This describes, surprisingly, us. “Are human beings noble in reason and infinite in faculty,” as William Shakespeare famously wrote, “Perfect in God’s image as some biblical scholars have asserted?” Hardly. We are a long way off. How good are we at rational thinking and making sense of the facts that are given to us?

Remember this? It was just a couple of months ago. We’re still here. I took this photograph on Friday the 13th. Just a moment there whilst our rational brains digest that. Friday the 13th. There’s even a name for the whole belief. I was in a hotel that didn’t have a 13th floor. Of course it did. It had a 13th floor, it was just called 14. The only way you can have a building without a 13th floor is to have a 12-floor building. Apparently you can fool the fabric of the superstitious universe by just changing numbers. It’s that easy. Apparently you throw a Friday … That’s just basic triskaidekaphobia, but you throw a Friday in it, and then that becomes paraskevidekatriaphobia. Yes, there is a word for it.

I read this in the paper that morning. By the way, just to make this even more significant, this is the World Trade Center site. I was in a hotel by … I opened up the paper, and there it is, the end of the world. I’m walking along, and there is a man advertising it, offering me the end of the world. I had to take a photograph. Are we to read anything else to this? We love looking at co-incidences, we are not reasoned. When I put this up on my Flickr group, joined a street photography group. I put this up. Somebody observed, everybody in the picture is male. Should we read into that as well? Actually turns out there’s one woman, if you look really closely. Can we read too much into coincidences? We are not prepared for software development as human beings, we’re just not up to it. Well, somehow we manage.

As a bit of fun, the key point here is to play around with ideas. This is a [perchuritous 00:46:19] piece of code. Let’s go back to some fun. I did a talk with [Anna’s Noras 00:46:23] in Norway in June, where we decided that we were going to illustrate the fluid principles as opposed to the solid principles and we would use each language only once and we only had a couple of examples. One of them was to figure out the next Friday the 13th. We wanted to show how you could abuse even ordinary innocent languages into being functional. It turns out this is ParaShell. You can do … This is a major abuse of PowerShell in the name of functional programming, and it turns out you can do this. It’s a bit of fun.

What is the point of doing stuff like this? There is a point here that is a little more deep. This is the exploration of practice in style. It is just in the same way that we have … Writers will say to each other, “Okay, try and write this in the style of William Shakespeare. Try and write this in the style of Ernest Hemingway. Try and write this in the style. Well, try and paint this.” Painters will do this. “Try and emulate somebody else’s style.” Get a feel for what’s that like. Try and learn something about it by doing that. You end up coming back to your regular stuff with a fascinating new insight. Sometimes it triggers something deeper. Sometimes it’s just fun.

I think one of the best ones I’ve ever heard is tell a chicken cross the road, why did the chicken cross the road? Do that joke in the style of Ernest Hemingway. Why did the chicken cross the road? To die. Alone. In the rain. Yep, we explore this stuff, we are playful. This is one of the ways in which we learn. These little fragments that we put together. I’ll leave you with a little bit of XKCD, actually I’m not going to finish it. XKCD is a wonderful profound insight, the same time it teaches us there is humor here. A lot of it is very geeky, and it also tells us about ourselves. The whole point here is that we are not well equipped for the facts of the universe, and to make sense of them. Yet, we are invited to encode them.

We’re invited in groups to encode things that will make a difference to other people’s lives, so we better get good at it. It’s important observation made by Douglas Crockford in “JavaScript: The Good Parts.” Programming is difficult business. It should never be undertaken in ignorance, which leads me to another definition of code that I want to explore. A code is a collection of writings. This a more slight more historical usage. People use it to refer to a canon of writing, or a collection of things. The notion of a code. If we are talking about fun and learning, and I started off by saying that there’s a bunch of stuff that we already know, that we have already learned, and that we can already be challenged by.

Turns out that software development has a literature. I’m not just talking about programming classics. I’m actually talking about code itself as a composition. It has qualities. It has styles. It’s provocative, it’s ambiguous, it’s challenging, it’s historical, and it’s important. This code goes back decades. We actually have, of all the disciplines of composition, whether we think of poetry, a writing fiction, it turns out that writing code has an abundance of this stuff, and most of it is now online. Well, most the good stuff. The rest is what we call enterprise programming. I’ll come back to that.

What can we learn about this? How can we challenge ourselves? This is interesting. This described by a games programmer in a blog. I know the games programmer, guy called Thaddaeus Frogley, as the greatest program ever written. This is Zed80 code for the Zedex81 computer, 1983. It’s written by guy called David Hahn. This is a chess program. It is written in 672 bytes. Let me update that for that. It’s written is just less than five tweets. This is the rules of chess and basic AI in which to play chess. This is the greatest program ever written. That’s quite astonishing. I’m not suggesting you go and put this in your commercial systems, but to understand that such things are possible, completely changes the way you look at certain things.

We have other wonderful pieces of historic code. Sadly, the resolution here is not quite brilliant, but the first comment there is, “This is the philosophy of Guildenstern.” This is the code for the Apollo lunar module. This was an astonishing piece of coding. Not only because it has a nice little comment further down, it says, “Temporary, I hope, hope, hope. Temporary, I hope, hope, hope.” This code was written out using a high level language, this is the high level language, and then compiled by hand over a series of weeks and then put into rope memory. For those of you who don’t know what core rope memory is, it’s basically a form of ROM that’s been knitted. Yes, there were … It turns out the 1960s, you still had a lot of people who would sew and knit and so on, and yeah this is it, the nearly 64K, by modern standards, of memory was knitted, and it took people to the moon. This is profound code, this is very historical.

But there’s also something interesting that teaches us about our own fallibility and how things could have been very different. Turns out there’s two bugs, and they canceled each other out. Yeah? When people retell Apollo 11, when they retell the landing sequence of how Neil Armstrong had to take manual control in the stage of the descent, and he was left with barely 30 seconds of fuel on landing. People always look at it from that point of view. It would have been somewhat more tragic had it been a software bug, but it turns out there’s one bug that canceled out another. A regular expression match, and not the full blown RegX, but just the core, typical [inaudible 00:52:57] in a page. That’s quite impressive, and in fact it’s very impressive and it actually has some interesting performance properties. It’s not perfect, but the brevity of it and actually a realistic example of recursion, this is quite profound.

To study it and learn from it. It tells you how short stuff can be and be useful. [Jay Uno 00:53:17], this the 3.X, [inaudible 00:53:21] the earliest one I was able to find online. As Martin Fowler once described it, “Never have so many owed so much to so few lines of code.” To understand this, helps you understand and demystify this. I encounter so many people who are mystified, they think there that there is something profound and complex about a unit testing framework, but there isn’t. There’s something profound and simple about unit testing frameworks. They have a similar anatomy, there is a certain simplicity that, if once you understand it, you’re invited and you feel like you want to create that simplicity in your own code.

We also have things that challenge us in very different ways. This is a very interesting example. It’s by Irvin [Unroo 00:54:02], of [Seamens 00:54:03], 1994. This is C++. Irvin was a member of the C++ standards committee and this program, when complied, prints out the first few prime numbers as it’s error messages. Now, that’s playful fun, but actually it turned out this was the beginning of template meta programming and the realization of how you can actually do functional programming at complied time in a language like C++. It turns out that templates are [churing 00:54:32] complete. A complete accident, but an interesting one. One that is … Everybody is jumping on the functional programming bandwagon these days, but it turns out it was there underneath your noses in a language that people think of for other reasons, for bashing bits or job security or something like that.

There’s a lot of stuff here. We have a very large literature. We have stuff that is profound. Peter Norvig’s 21 line spelling corrector written in Python. That’s quite impressive. This is one of those ones where you type color and you get back colour. Oh, sorry, let’s just clarify that for you. Maybe I make a mistake when I’m writing and I write … And it says, “No. Did you mean?” You’re right, thank you. That’s what this does. This is profound. It’s short and it’s a wonderful exposition of some very … Really understanding and using a language to it’s full. We have what we describe by Alan Kay as the Maxwell’s equations of computer science. This is originally a lisp had an eval. It was lisp, written in lisp. This is profound. That was written in the late 1950s. This is taken from structure and interpretation of computer programs. This is Scheme, written in Scheme. Alan Kay was so inspired by this that when we originally envisioned small talk, he wrote out small talk in small talk. Basically this is the kernel of what it does. This is the eval.

Dan [Ingalls 00:56:13] went off and implemented it, but he was working from home. It’s the early 1970s, what kind of computing access are you going have at home? Yeah. You’re not going to have a lot, but this was the age of the early ages of time sharing. What language’s available in time sharing systems? Basic. This is what I love, is that whenever anybody ascends to these real height, small talk it’s so pure. It was implemented in Basic. This is the topsy turvy world we live in, but there are other aspects to this. The simplicity of this, also allowed Guy Steele active theories come back into fashion recently. I did my masters thesis on it about 20 years ago. I’ve very interested in active theory. Turns out that Scheme was invented created to explore active theory [inaudible 00:57:09] active theory, and he had these expressions, called alpha expressions. But it was when … Because of the simplicity of the code of the eval, Guy Steele looked and he said, “Oh, that’s funny. Alpha expressions have exactly the same evaluations structure as Lander expressions.” Unification moment. There was light and all kinds of stuff and angels or bits or something like that.

The whole point here, that was only visible because of the simplicity and elegance of the code, because you could see that on a page and go, “Hey hang on, those two are the same.” That’s not just case of let’s refactor the code, it’s let’s re-arrange our understanding of what we’re programming. Now, it’s very easy to say, “Well, look these are all these.” Let me just show you a bit of fun. Regular expressions. This matches prime numbers. If you put in a sequence of ones, it will tell you whether or not you have a prime number of ones or not. That’s amazing. Again, don’t put this in your code. Actually, if you’re working in Java, it’s okay, the Java regular expression [inaudible 00:58:12] doesn’t work for this, but it’ll work in Pearl and Ruby.

To understand these, these are little examples that excite and tease us and challenge us in ways that we should be excited and teased and challenged about, because they’re about … The stuff they get you interested. They bring out that passion. Oh, but Kevlin, these are just toy examples. Yeah, but don’t you like to play with toys? Wasn’t there a Lego session here? Aren’t toys fun? Isn’t that one of the ways in which we learn, but if you want bigger examples … Oh there’s two more toys. That’s my boys’ light sabers. Not sure whether they’re going for Sith of Jedi at the moment. Although, as parents, clearly we have our beliefs.

This is “Lion’s Commentary on Unix, 6th edition.” This was a cult book before it actually became a book in the 70s. This includes the whole source code for Unix. All 10,000 lines of it. With commentary. Introduce you to it. It is a style and a culture of a by gone age. It’s wonderful, you look at it and get that, oh you wouldn’t write [C 00:59:12] like that now. It would break so many conventions, and yet there is something here that we should spend time looking at. 10,000 lines. That’s amazing. I’ve seen classes that are 10,000 lines. I’ve now actually taken … In fact, you can try this next time you see one of those monster classes, you say to somebody, “Wow, Unix used to be 10,000 lines. Your class is 10,000 lines. It must be doing something very important. Because you used to be able to write a whole operating system in that.”

This takes us away from the realm of enterprise code. What I want to get to here is that when people sometimes talk about craftsmanship as an approach, a style, they often refer to it from the perspective of software development is a discipline that is young. That is why it is … It’s just a craft. It’s immature. Well, this is quite frankly insulting to people who are craftsmen. It’s particularly given the crafts used to be carried out over centuries. That’s definitely not immature, but it’s to do with how we use our knowledge. This takes us back into learning. There’s a very important consideration about how we appreciate how we learn stuff. It is, and again, [inaudible 01:00:29] … We don’t have a lack of experience. Software runs the planet. It’s actually quite scary, it turns out if you start … I read a piece recently on GPS.

If the GPS system failed, it turns out a lot more of the infrastructure … It’s not just a few people who would get lost. The GPS fails, not just a few people who get lost. We’re talking trains crashing, we’re talking about airplanes falling out of the sky, this is fairly big. This is all software and computer related. All that money, all that frustration you have with your bank, is created by software. All of this stuff, it turns out we have plenty of experience. It’s how we use it. We have come to value the idea of learning from our mistakes, but there in lies the rub. We need to be very careful with this, because there’s a whole set of beliefs that have grown up around this.

Beliefs that are actually not rational when we look at the facts. We built up codes of practice based on this, quite literally, codes of practice. This is from the Financial Times. “It has become commonplace to suggest failure is good for entrepreneurs. In this view, failure comes early in a founder’s career can teach them important lessons about doing business and harden them up for the next start-up attempt.” This is standard ideology, you can find it in things like the Financial Times. You can find it spouted in the columns of many papers. The Economist, in an NBA course. Let’s actually look at the facts.

“In the UK, the evidence is that novices are neither more nor less likely to have a business that either grows or survives than experienced founders. In Germany, where much more extensive statistical work has been undertaken, it is clear that those whose business had failed had worse-performing businesses if they restarted than did novices.” This is exactly contradictory to what you have been told. Why does this matter? Because the code of practice we have built up and sure, the assumption of entrepreneurs use the lessons of their own experience to improve their chances of creating a series of profitable businesses is not born out by the evidence. We’ve looked at evidence and it turns out that we do not learn from our mistakes. Oh, sometimes we can, but that’s not the same as we do. Do and can are very different words.

It turns out, when you look at the neural level, experiments have been done. Looking at the learning process of the level of neurons shows how brains learn more effectively from success than from failure. This is the most important insight. We are terrible at learning from failure. We can sometimes learn a bit from failure, but we’re not actually wired up to do that. That’s not the natural state of affairs. It turns out that when you do something and it works out in your favor, you remember it. The relationship between the neurons, the connection is reinforced, but if you fail, basically nothing happens. That path is open again to allow you to fail in exactly the same way. It does not get taken away. Oh, that didn’t work, right? Rip that connection. It doesn’t work like that. We’d like to think that it does, but it’s not how we do it, which is why people produce classes that are 10,000 lines again, and again, and again.

We know this is not good, we know a whole load of stuff about how to produce good software. Why is we seem to struggle? When people say you learn from your mistakes, you just don’t. It’s as simple as that. We are not wired to. Now, my older boy was learning piano last year, he’s given it up and decided the guitar probably is more of a rockstar thing. While he’s learning piano, it’s important to understand how he learns piano. Or rather, how he didn’t learn piano. The piano teacher did not sit there and say, “All right, here’s some music, play it.” “But I don’t know how to read. I don’t know how to read music.” “Oh, just play it.” Bing. Wrong. Bing. Wrong. Wrong. How are we doing? Have it learnt anything yet? This is a terrible way to learn. It’s just completely the wrong approach. Right, think of a number. Somebody give me a number.

Speaker 2: 24.

Kevlin Henney: 24. What kind of numbers’ that? Come on. There’s a few.

Speaker 3: Five.

Kevlin Henney: Yeah, those are all wrong by the way. I’m expecting things like 42 and seven. The least common random number between one and ten. If you ask most people, give me a number between one and ten, it’s seven. Small numbers, these are all wrong.

Speaker 4: Five.

Kevlin Henney: Oh, good. Good. Nice. Wrong. Good thinking, yeah.

Speaker 5: [inaudible 01:05:06].

Kevlin Henney: Oh, challenging.

Speaker 6: [inaudible 01:05:11].

Kevlin Henney: Oh, interesting, very geeky. I like that one. I’ve not had that one before. No. 299792458, which is C. The speed of light. How long would it take you to find that? Once you’ve got the idea, I primed you a little [inaudible 01:05:26], you can spend a long time … We do not learn arbitrarily from these thing, you have to learn against a context of success. This is one of the ways in which we learn. It is also one of the reasons that I find myself fascinated and drawn to the discipline and the domain of patterns because there’s very simple idea. Do you know what? We haven’t had a manifesto for awhile. Ah, there we go. Patterns manifesto. I decided to keep this one intentionally short. “We are uncovering better ways of developing software by seeing how others have already done it.” Well, that’s it. We’re done.

I put this up … I was running a workshop for a company in Norway, where what we were actually doing was we were … Going back to this idea of knowledge. Code contains our knowledge. It contains our beliefs about how we’re going to build a system. When you look at a code base, it’s like this is how we believe the world around this system, when this system is formed. This is we, as a collective team, over the past and the present and connected to the organization, these are our beliefs encoded in a form that is ready for execution. Sometimes when I always put it like that, people say go, “What you mean, that that’s our knowledge? Wow, that’s messy.” We have messy knowledge, yes we do. Maybe we can tidy it up by recognizing it as such. Removing that notion of liability.

What we ran here was a … Of course you can tell this is software developers. We have coffee, we have pizza, and we have whiteboards and Post Its, and what we’re doing is we are pattern mining. We are trying to find out what are the things that make your code, your code? Imagine I were to join your team, what patterns, what vernacular, what idioms do you use that I might not already be familiar with and yet somehow are central to the way that you communicate and create the system. What is your dialectic for this system? How do you frame the universe? What we’re doing here is just mining the patterns they already have. That’s a really key idea, and it takes us back to that … At one point, I can’t remember what happened this week but I think somebody released another manifesto. I seem to remember not being overly impressed, so I wrote a manifesto that could fit into tweet and put it up and it was just like, yeah that’s right. What’s also interesting is when I did actually tweet it, a couple of people tweeted back amendments, and corrections, and corollaries.

All of which said exactly the same thing but with more words. Brevity matters. I said I’m interested in writing a little bit of fiction. I write mostly flash fiction, which is short. Try and tell a story in very short forms, say 500 words. There are different forms of this, there’s a dribble, which is 50 words, and there’s a drabble, which is 100. There’s a drabble and a half, which is 150 and so. What is interesting about this and twitter, is that it gets you focusing on brevity. We can do the same thing with code. It gets you trying to think, how do I communicate the stuff that I know and wish to communicate. Brevity does not mean obscurity.

I’m going to close with one last definition, or I’m almost going to close, but this is the last definition of what I think covers the things that code has meant to me. I want to get across that idea of a codification. The idea of a formal expression, representation, collection of knowledge, beliefs, and relationships. We use it for communication, reasoning, and action. This is the code that binds us as individuals to how we work with each other to our organizations. It is the collective works and set of knowledge that we have accumulated as a group of people, not merely as an individual and it is also the thing that we write in order to be executed, there’s all of these things.

The bit I didn’t include though, was the obvious thread that’s been going through all of this. It’s fun. This should be fun and passionate. If you want good code, it turns out happy people tend to make a big difference. Motivating people with business value is not enough. You get that not by aiming direction for it, you aim indirectly for it. That’s how you do it. So I’d like to leave with this quote that I used from the american broadcaster, Edward Murrow. I used it in the preface to “Ninety-seven things.” “The newest computer can merely compound, at speed, the oldest problem in the relations between human beings, and in the end the communicator will be confronted with the old problem, of what to say and how to say it.” He said this … Let’s put it this way, he died in 1965, and this is still remarkably fresh. Thank you very much.

Speaker 7: [inaudible 01:10:12] We have time for a few questions. Do you have a question?

Kevlin Henney: Right, so anybody got any questions? Just to clarify, reading out URLs is not very helpful, but you can ask me about URLs for some of these things if you care about them.

Speaker 7: Any questions?

Kevlin Henney: No questions. That was all perfectly clear or are you still hungover, or? No, that was good. Right. Well, thank you very much.

Speaker 7: All right. Thank you. Excellent.