 Not much to say, but please give your attention to our dear friend, Chad Fawley. And it's developers. I wrote this book, this is a little plot, it's not about this book, the talk is not about this book. But we are all passionate developers. And as passionate developers, we are out in the world, people like Ryan Davis are kind of like freedom fighters. Fighting for software quality. Fighting for what is right in software development. Because we're passionate, though, and because we spend a lot of time doing that fighting, we can develop some kind of rigidity about what we believe. So that's what this talk is about today. A lot of us come from this kind of craftsmanship idea of the world, and this movement resonates with us. These books came out over 10 years ago. In fact, I read software craftsmanship, the new imperative on the way to the first Ruby conference that we co-organized in 2001. Kind of amazing. And we've been living with these ideas forever now in terms of my professional career. So you can kind of run into this thing where it sort of feels like a religion. The issue, and what I'm going to talk about today is that we have no idea what we're doing, relatively speaking. We're all passionately chasing this thing that's based on emotion. I sat at lunch today, and I talked to a group of passionate developers about conference organization. And I've heard something that I hear very often in the Ruby world. I think the Ruby world is especially passionate and also especially prone to the kind of mistakes that I'm going to describe today, through personal examples. And that is that we feel like we're out in the world spreading something that's good, almost like missionaries. So there are a lot of religious overtones to what we do and the way we behave as developers. It's really kind of strange. I was sitting at lunch, and I kind of, I get swept up, and I believe in everything that's saying, and I took a step back, and I thought, why do we care that there are more Ruby developers? Why do we want to spread this thing that's bizarre? It's a programming language. It doesn't really matter, you know. If people program in Java forever or C-sharp, it really doesn't matter as long as we do stuff. Anyway, welcome to the story of my ignorance. I'm going to tell you a little bit about my background, how I got where I am, and some of the stupid ideas that I've had. And it starts here. So this is me. I'm the one on the left, playing saxophone. This is my previous career. I was quite successful by the standards of a professional musician. And by that, I mean, here I am playing at the prestigious Memphis Zoo. Yes. In front of like an office or something. Yes. When I was pretty happy, I was playing maybe 10 times a week. I was playing weddings, I was playing feel-free every night. But I started kind of thinking about my life, and I thought, how am I going to ever make any more money than this? This really isn't scalable. Not that I said scalable when I was a saxophone player. And not only that, but how am I going to afford you? Unfortunately, I was going to eat at the Tolls. So if you saw me years later, you saw that there were ramifications to that as well. And do I really have to play Mustangs Alley? Mustangs Alley is in the key of C as you're hearing it now. Strangely, and Memphis also from the key of C. And they all have this tempo. And when you play saxophone pretty well, even dance, you have to play solo for 15 to 20 minutes while the song continues to drone on the same chord in the key of C. So it's kind of sad. And what I really wanted to be doing I realized at that time of my life, like right now, I'm sitting here. You can tell I'm kind of looking up into the air and thinking about something other than the riff, the Mustangs Alley. Well, I'm really thinking about it. So I would do a whole thing, maybe three at a time, see if I was ghetto, back then that's my dream. And I would sit down in my computer and I would play Doom. All that Doom death-match, death-match. I would call people in Canada. I don't know how I form this, because you got to actually make phone calls with people. And it was like long distance international calls just so I could play like a two minute name of Doom. And then I would go on and I would start thinking, wow, this is amazing. I love Doom. It's kind of like really, really fast chest. It's maybe one of the greatest human endeavors to have created this thing and given me the opportunity to do this. And I was probably better at Doom than anything I had ever done up until that point in my life, including playing saxophone, which I had studied in school. I practiced and practiced and practiced. So that made me think, well, I want to be able to do this myself. I want to be able to make Doom. How do they do this? How do they actually, like do they type something into a text editor? I remember having this conversation with a friend saying, what do you do? Do you type something into a text editor? How does it become this thing that I can play? Why can't I read the text? How does that work? And I would stay up all night. I would get up like a VAC system from the University of Memphis. And I would need to go for it. And then I started doing like DCL or whatever that was called because I thought maybe I could make it to this. I don't know. But it ended up being like a local guru in fixing people's Doom installation and playing around with Doom Analysts. And obviously one of the best Doom players in Memphis and in the world. And this led to the next natural progression in my career, which was to get a job in corporate America program. So here I am. You can see me there. I'm going to go, but it's not really a picture. So we're having a picture. I got a job in a corporation in a cubicle. And I thought, wow, this is awesome. I got it made. People kind of dress funny. That's all right. I'm okay with that. I kind of dress funny too. I got my own little box that I could sit in. I could listen to music. And I had a CRT. That's a capo and ray tube for you guys. And you don't get into music because you want to make a bunch of money obviously. That's why I was out of it, right? Well you do get into music to do is you get into music to be awesome. You get into music to be like the best in the world. Nobody starts playing music thinking they're not going to be remarkable. And to me, that made this whole craftsmanship idea really resonant. Because I used to stay up all night like writing music and thinking and analyzing stuff and practicing the saxophone. I remember actually sitting up one night I had one of the early wind instruments, an electronic wind instrument. I wonder what you have in mind. Early electronic wind instruments that I could play with headphones. So I went to the store with my roommates and I literally spent all night non-stop improvising over the chord changes for giant steps by John Coltrane. So I took that same, by the way, giant steps by John Coltrane as an atrocity. If you think that's good music, you're wrong. Okay. I love John Coltrane, but not giant steps. It's just a mathematical experiment. Get over it. But I got that same kind of thinking of really caring about the craft. And this clock is not moving, so I have perpetually 60 minutes. Awesome. By the way, I shouldn't have an hour. The other people who spoke today should have an hour, and I should have 30 minutes. Whatever. That's the thing about me. So everything was okay. Sigma. In Sigma, they use words like master black belt and green belt to describe people. Now, when they did this, I was like, you didn't say any of this shit in the interview, and now I show up to work and you're calling people green belt. This is not okay. But I moved. It was like, wow, I just moved to a new city to listen to people call each other green belts. Talk about all kinds of strange stuff like this. I mean, people at this company were just like, lemmings following this thing around. It was GED, by the way, in case you're wondering. It was ridiculous. And it was scary. These people were getting paid a lot of money and they're just saying, crap. It's like, whoa, here I am. And I thought I was really trying to be in a good situation where I could focus on the beauty of the craft of software development. I know everybody's saying all these crazy words, but they actually pronounce them like demand me and they don't laugh when the other one says it. So I thought, what have I got myself into? It's nonsense. It's like, babble, you know. What a bunch of crap. Anyway, I started thinking about it and I realized that there were some things that we would talk about that just sounded the same to these people, you know. For example, abstract factory singletill facade, flyway builder grin, et cetera. So at that point it's like, okay, whatever, I can live with this. I've got my cubicle, I'll put on some headphones, I'll listen to some really offensive music and nobody will know I'm gonna be happy. Just write some software. Then I had a conversation that ruined it a little. Went something like this, talking to a manager, crafting high quality software, so happy. This person comes along, this is a real story, and says, give me a process for developing high quality software. Document it and give it to me. So we can hire more offshore developers. I just can't ignore this thing, you know. And the conversation that I had after that, I probably ruined the rest of my career at that moment at the company because I said something like, you give me a process for writing a beautiful song or creating a beautiful piece of art. Just write down the list, write it down on a list and I'll hire a bunch of offshore songwriters and have a bunch of awesome hit songs. What does that mean? That's the basis of many of the decisions that we make in our field. I mean, Ryan was getting pretty kind of quantitative about it, kind of concrete. A lot of us just say, you can't do that. You can't hire cheap people. You can't think about cost per hour. You can't offshore stuff, put it in cheap locations and get people who are passionate because they're gonna develop stuff that's not high quality. And then we have this whole kind of thing like look at all the testing tools and libraries that we use in the real world. Is that quality? What is quality? There's a bunch of different definitions for quality. I like this one. The adjective of we're having superior quality. So I posted a message on Twitter because this is how I do talk preparation these days. I have a bunch of followers on Twitter who are programmers so I say things like this. Developers, can you define software quality on a single tweet? And I got a whole bunch of single tweets from single word discipline. Quality software does what it should. It's easy to change. Quality is practically polish. What do you do with people from Poland? Anyway, here's my favorite one. No. No. So change, like making software really change, clean, beautiful, fast works, cheap, extensible, shiny, et cetera. That's the kind of stuff I heard. So I went to the source of all things about quality. If you have not read this book, you must not have ever seen me speak because I recommend it constantly to the point where you will read it so you can stop hearing me say this. Please read it. It's really good. Anyway, here's a quote from the Art of Motorcycle maintenance. With quality as a central undefined term, reality is it's a central major, not standard, but dynamic. So if you have this problem of not having quality defined, you can turn it into this and think, well, hey, man, that's kind of cool. Let's just not define it. I can deal with that. That's cool. I'm a really programmer, you know? Really programmers like things to be dynamic. They like things to be kind of, you know, we're a bunch of hippies, right? So I'm comfortable with this kind of fluid definition of something that's central and important. So I can kind of go with the flow. But there was trouble learning below still. No matter where I went, I would try to kind of rationalize my way around these problems and fix them, but I couldn't. Because I'm getting submerged, submerged. I'm getting immersed in Six Sigma and submerged in Six Sigma. And if you look at Six Sigma, anything about it, you're gonna see the word quality. That's gonna be all about measuring quality. I cannot ignore the word quality now. I can't just kind of go on and say, okay, whatever, I'll define quality. I tried to, and they would say, well, measuring what is the output signal and what are your metrics? Like, I don't know, I'm a software developer. It's good stuff. That's all I know. It's good. I'm smarter than you, and so on. So here's the issue. Quality, a variety of definitions. And there's kind of continuum of how you measure it and how you talk about it. So on one side, you have the one that I was using, which is form. This is beautiful software, shiny, stuff like that. And then on the other side, you have function. And that's where the kind of commodity things are. In the middle, you have crap. Somewhere there in the middle. So let's look at some things of varying levels of quality. This is a worth Rothko painting. This is a wall. Here's another wall. Which one has higher quality? Retourful question, done answered. Music. Oh, please! It's also pretty beautiful. This is what's on sale on wall. But which one has higher quality? Now, here's an interesting thought experiment. How many of you would be comfortable, and just imagine if you're not a woman, imagine you are. So, or imagine the male equivalent of it. Or imagine you don't mind wearing a dress, regardless. How many would be comfortable wearing the dress or the Christian Dior dress? A couple. How about the Pulse Netsuit? See, we're in Seattle, so some people actually would. I'm guessing that the vast majority would actually, all things being equal, prefer to wear the Walmart thing. As ugly and boring and run-of-the-mill as it is. So sometimes the subjective artistic quality is not even desirable for our audience. This is a Ruby conference, so I'm gonna have at least two slides and have something about Ruby. Here's one of them. This is a server that Prince asked the cats. I have to admit the hard part is not in this code. This is the server part. It's a Ruby 1.9 application, as you can see by the beautiful symbols on the code. Here's a high quality piece of software right here. So which one of those has higher quality? How do we know? How do you talk to someone who's a client of these things about this high quality? So on the different ends of the spectrum, we have subjective measurement. We have objective measurement. The Walmart pants probably have the fit and they don't fall apart. That's about all you need, right? And then cost is part of the quality. The Christian Dior dress, it's sort of hard to measure. All you can do is either like it or not like it. I think it's beautiful or not beautiful. So what I'm thinking here is, and what I sort of filtered through the ringer with this corporate experience is that calling quality for software subjective and just purely leaving it at that as a comment. There are measurable things. We're not creating the part. Sometimes we're not even creating graph. Depends on what our users want. So I had this conversation with a master black belt at GEE who told me internal quality doesn't matter. The idea is there's external quality which is the actual performance of the product, whatever that is. And then there's internal quality which is all the stuff that I cared about. How is it organized? What are things called? That sort of thing. Now I used to talk about maintainability but I had no measurement for it. So you could say that maintainability itself is important, which we'll talk about might not even be important is external quality as well. So internal quality doesn't matter is the conversation I had with him which just drove me crazy. When it really comes down to this, who gives a crap about form on the form versus function scale? So how many of you write code for businesses, government or educational institutions by show of hands? Those of you who don't, what do you do? If you're not programmers, that's fine. Pretty much all of you and I'll just discredit the rest of you. So here's what your customers think about form versus function. Something like this. Maybe they care a little bit about form. It's probably more like this. They really just don't give a crap. Doesn't matter. It doesn't matter if it's beautiful as long as it does what they want. And maybe that you're saying, well it needs to be maintainable, they don't care about that either in some cases. It's all right to throw it away. If I have money, I can say do this one time and have it work the one time and I'll just pay you to do it again later or pay someone else. I don't care. So here's something that I sort of learned from the Six Sigma World. If you can't observe something, it doesn't actually exist. Sorry for religious people. I know there are people who take exception to this. I'm not talking about religion, I'm talking about our jobs. So here we have people with kind of two different takes on this. On one side we have Justice Potter Stewart who was famous for his judgment on pornography where he said basically the definition of pornography is I know it when I see it. That was in a Supreme Court case, amazingly. And on the right, we have Imel Haytham who was credited with starting when it has become the scientific method. It kind of comes down to that. Oh no, I know it when I see it is what we try to do in the software community, in the software craftsmanship. But there can be science to some of this stuff. There can be engineering to some of this stuff. So if you can't measure it in a way it isn't real. It isn't something you can talk to someone about unless they have the same kind of subjective opinions that you do. So we already know this. This is Donald Pernuth. We mature our optimization as the root of all evil. We all kind of believe that, right? Except those who don't really get it. The rest of us believe this. We also in this room are probably all pretty much in the kind of tax driven development world. In a way that's a case of measuring something. So we get the idea of measuring stuff but then we keep talking about code quality without a great way to measure it. So I don't think we actually know what high quality mode is. What we as developers like to do is solve the most convenient, automated problem that we can find. And if it's not automatable and therefore measurable we don't like to think about measuring. At least that's how I am and that's how many of my peers have been over the years, but not all of them. So the problem then is what do we measure? So if we want to talk about quality and make a measurable thing, how do we do that? How do we break down something that seems so big and potentially even artistic and crafty or whatever you want to call it and measure it? And this is where Six Sigma actually has some good ideas. So I'm not gonna spend the rest of the time talking about Six Sigma, but I'm gonna just briefly go into one part of that. This is the Six Sigma kind of workflow or life cycle and you'll see here on the battle slide that's actually like demand V and demand. Those are just acronyms, really bad acronyms for two different processes in the Six Sigma world. So there's the idea of designing something new and then improving something that exists and that's what you see here. So conceptually we can probably all kind of get behind the ideas that Six Sigma promotes, which is you think about things and measure and analyze, maybe not really slowly, you don't have to do it slowly, but you think about things, you make them measurable, you design, you actually validate, PDD is kind of like that, that's how you create something new and then when you want to improve something, for example performance on a piece of software, you define what the problem is, you measure it, you analyze what the issues are, you make improvements, you validate your improvements and then you put a control plan in place where I think Ryan actually just said that for the year old stuff, they put in kind of control plan for performance of payroll using any case. So the framework that Six Sigma provides designed for Six Sigma or demand V as they unfortunately call it, it looks something like this, there's a whole bunch of different, like they call it tools and sometimes it's tools, sometimes it's just ideas, patterns, process patterns, et cetera, for doing these things. So if you look here, these are the different phases of the process and there's all these different things you can do. We're gonna look at one of them that I think is actually worth, at least exploring to stimulate some thought, not stimulate, stimulate some thought on the process of taking something that seems too abstract to measure and making it measurable and that's this thing, the Quality Function Deployment. So Quality Function Deployment is something you typically do with a spreadsheet unfortunately because that scares a lot of people off. But basically what it does is it takes fuzzy ideas and it tries to break them down in ways that make them measurable in a way that you can validate. And so you basically take high level fuzzy desires from a customer and the customer could be you, could be someone you're working for and you break them down. And it works recursively. So you take these ideas, you break them down into measurable chunks, you can then analyze and validate and improve and then you take those things and you make those be like the objectives and you keep going. And at the end of it, you end up with a transfer function for quality which is sort of ridiculous but it's at least provable to map to the things that someone asked for. And you can actually say like if I tweak this parameter it has a bigger effect than if I tweak this parameter rather than just trying to guess and follow your own judgment subjective ideas. So here is a zoomed in kind of idea or a zoomed in look. The way this works is on the left side you'll just list the high level things that the customer is looking for. So that's there on the left, what the customer wants. So here we're talking about cookies. The customer wants good texture and generous portions and tastes good. All these sorts of things that are totally subjective and are the kinds of things you talk about when you talk to your customer, right? Then up here, you brainstorm technical requirements that will actually drive those things. So appetizing appearance, color, we're all concerned with tensile yield strength. Wait, I ripped this off from somewhere obviously. All these different things that are just measurable items. These are the things we like to focus on to actually drive the things the customer asked for. And then you see we map strength, like correlation between those things on this grid and whether it's positive or negative, strong or weak, then you end up with target values. And you get those by actually testing the things, putting together examples of all these different variables and seeing what they lead to, maybe just in terms of asking the customer, now that I've done this, what is the correlation between these settings and yourself? And there's the relationship strength. So in a way, once you've validated this spreadsheet, you kind of have a high level view of taking something that is not easy to measure and breaking it into measurable pieces. You can then validate how those pieces affect the measurable part. And we've already done something good. We've taken something fuzzy and made it more concrete and measurable. Then, oh yeah, it creates auto-generated priorities where you can probably figure out yourself that would be possible once you get all these pieces in place because you've got weightings and everything. And you take that whole top section, which is the weight and the color and all these other things and you recursively stick it in another one of these, put them on the left and then on the top, you start listing the broken down version of how you can affect those things with, again, smaller, even more measurable pieces. And that's how ultimately you end up with, you actually do experiments, we're probably not going to do it for every piece of software, right? We're just thinking here. But that's how you end up with transfer functions, formulas for quality as the customer defined it. And we're talking about cookies here. So, if you can actually measure quality of a cookie, you will probably measure quality of a piece of software that you're writing. It's probably a little easier than measuring the quality of a cookie. But you have to actually worry about the definition of quality, as opposed to just kind of using it as a word that allows you to stop having rational conversations. So then, you validate the results. So that's the whole idea, just like T. So we have assumptions, we have targets. Dave Thomas did a talk of magic ruby, which was roughly the 10-year anniversary of the authoring of the agile manifesto. He's one of the co-authors of that. And he boiled agility down to this. Where do we want to be? Where are we now? How do we revert to our position? And then, you just keep doing it. It's kind of funny. That's what this is. This is just more formalized. So when I first saw Six Sigma and agile methodologies, it was XP back then. I thought, wow, listen, this kind of is the same thing, but one sounds more stupid than the other. And it might have been XP. Extreme programming, it's a pretty stupid idea for a name. Anyway, so this idea of actually applying kind of scientific engineering thinking programming is obviously not mine at all. It's been screwed up over the years and recently some really smart people have been thinking about how to do it right. This is Mike Feathers at Rails Club last year, he was talking about what is bad code. He showed us a Java code and there was a method that was obvious of something we all wanted to re-factor when we saw it. He said, is this bad code? And everyone said, yes, it's bad code. But then he said, what if I told you this code works and has never been changed since the first time it was created? That makes you think, okay, what's bad about it? The first thing is, all right, it works, that's fine. We're running a performance problem as we can see. So the only thing you can go back to is, well, I can't read this very well and I can't maintain it, but the method name was okay. So I don't have to maintain it because it doesn't ever change. Maybe this isn't bad code. That's where I'm interested in conversation with you. And he had started doing a bunch of experiments where he was analyzing source code repositories. So we did a code retreat in Boulder. No, I was like, wow, it was in February of this year. Mike Cain, Corey Haynes and I, a facility at the code retreat, and the three of us got together and we made this tool called Turbulence. So you can jam and install Turbulence and it really just takes Mike's ideas and codifies them into a jam and it allows you to do some analysis. So what I'm done here is I installed Turbulence, and I ran it on one of our Rails applications at LivingSocial and I came up with this and this is a pretty small app as you can see. Basically you can see helper's models, stuff in the lib, stuff in controller, generators, and we're looking at the complexity versus code term visualized here. So you can mouse over if you get this thing. You have to write, the command line is B-U-L-E, you run it from, obviously that's the middle words of Turbulence, right? Everybody loves that thing. You mouse over and say that thing in lib there and you will find out what its flog score is, we're using flog, thank you Ryan, and what its churn score is and we've done that sort of a low budget kind of easy churn score. And we can see that the thing in the upper right is probably a good target for re-factory. If you look through this app and you ask what is bad code in this app, probably that thing up there. There might be something of really high complexity, in fact a couple of our other apps have stuff that's a really high complexity that's never changed. So I would say don't waste your time screwing around with that one. I have an interesting way to break down what seems like kind of subjective measurements but apply some pragmatic thinking. Glenn Manderberg has been talking a lot lately as well about engineering and software development. If you haven't seen one of his real software engineering talks you should seek one out. They're available on video, video from, I guess RailsBump this year, Ruby Hoedown last year, a couple of other venues, he's done different versions of it. But what Glenn has been saying is that we have given engineering a bad name because we haven't actually been doing engineering and software development. I think that's quite obviously true. Engineering is something that's proven to work and we just call things software engineering never bothered with the proof that it works part. Anyway, that's the end of my sixth-sign language field. Moving on. I'm gonna put that side up. The author says a burger better than a towel so I can ask you and you'd all say yes. Actually, it would be a burger just for the people. Then, can you sell a burger better? So that's the next question. You think about that. The answer is almost definitely no, right? Can you make software better than McDonald's makes burgers? Average, no, you cannot. This is the Standish Chaos Report from the 1940-2009. And it's showing here successful projects are the green ones. Challenged are the white ones and then red or fail. But challenge means like way over budget and or way over time. So in my book, that's also a failure. Which means based on this, which is just a survey and there's all sorts of people disputing whether this is valid, but whatever we know it is, we've been there, right? We're all programmers, we've seen it happen. We basically just suck all of us. All of us. All of us. All of us. On average, you all suck, I suck, we fail to deliver. It's just, I don't know why. It's years. Years into this thing and we're still not doing it right. We're still not in control of our processes. So what does McDonald's have that we don't have? So I would say that the first thing is McDonald's has really well-documented rigid systems in place. This is someone finishing an ultramarathon. So an ultramarathon is a race that is longer than a marathon. For people like me, that means 50K. For real ultramarathon, and I thought that I have a grand one, but I hope to. But 50K will be just right over a marathon length. That's enough to call it an ultramarathon that I'm done. For some people, it's 200 something miles. Or it's 100 miles through mountains, craziness. Humans can't really just start running and do this. You certainly don't start where I was three years ago and say, yeah, I'm gonna run 100 miles and just do it. And you also don't say that and think, well, I'll just practice and then I'll do it. Because you can't just figure that out. You have to put a system in place to make that happen. So if you look at the world of endurance sports, you can get some pretty interesting ideas. This is Keevee McMinn's training plan for her Ironman, the first one that she attempted. It actually failed completely. Keevee McMinn is a Ruby developer. Some of you may know her. She is now finished two, I think, yeah, two. She's finished two and she's completed three Ironman triathlons, which is where you basically cover like 3,000 miles on foot and then you fly by your own power. This is her plan for a year. And we can't really read it. It doesn't really matter what it says, but you can see February, March, April, blah, blah, blah. I went through this sort of a thing when I was going from being extremely obese to being able to run 5K, but my spreadsheet was much smaller, obviously. But I went through the same thing and every sports-related thing I've been able to make my sad body do, it's been through following a system like this. And I look at this and I think there is a strong chance that even though an Ironman seems impossible, if I had the willpower and the desire to do one and I got the same system that tweaked for me, I could almost definitely do it. That's pretty amazing. Going from I can't imagine how to do it to actually finishing something like this crazy Ironman race. I think most normal people could do it if they followed a system, but that's really the secret. Things that seem impossible to do well are possible if you have a system and stick to it. And so here's an example system from our field. This is actually no less complex than designed for Six Sigma or Kiwi's Ironman training. This is extreme programming and it's a flow chart for extremeprogram.org. But we kind of get these ideas already, naturally as software developers. Now, so the next step, when you find a system that works and you can then implement it, the next step might be then to start thinking about how you make that system run itself. A big problem we have in software development is that we focus on people, at least those of us who are craftspeople do, we think that it really is up to the individual programmers being excellent to make software come out and succeed. But what I've learned is that it doesn't really matter how excellent programmers are, the software projects still tend to fail. So if you can make a system, prove that it works, you might actually improve your results and work on making that system run itself. This is Ray Kroc eating a burger. Ray Kroc is the guy who found the McDonald brothers by going to one of the restaurants and said, you guys have made a system for making this work. I'm going to take it and start cloning it and copying it and turning it into a franchise. And the reason that I'm showing Ray Kroc here is the other book that I always tell people to read. The Myth Revisited, the second worst name of the book ever. The first one is my job went to India. That was it. So in the e-myth, this is about why small businesses fail. It's not about like e-commerce or whatever. That's why I always thought that name because I think that it's some e-commerce myth book. It's about feeling stuck inside of a business. It's about working in the business that you're trying to start instead of working on the business. As software developers, we tend to do this. You work in your job instead of working on your job. Pretty much all of us. But if we could all take a step back and look at what are the things that make me successful, maybe I can then start to break it apart and give it to other people. I think John Barnett talked about this a little bit yesterday, but make an order chart for what you do. I started doing this last year, partially because I was thinking maybe I could actually outsource some of the things I do because someone cheaper than me and it takes some time off. Workable, but maybe some did. Make an order chart and the example that like Berber uses in the book is with a single business owner. Making an order chart for everything she did and then documenting like coming up with job responsibilities and titles for everyone in that order chart. Making a system out of it, getting to the point where you could then hand off pieces of it to someone else. Because there is stuff you do that you don't have to be the one to do. No matter who you are, how smart you think you are or what you work on. So you can organize this into an order chart. And then once you have that order chart, you have this hierarchy that you think about in different pieces of what you do as a software developer, map into different pieces of what makes a software good. So you can potentially take the things from the QFD quality function deployment. More you'll have ideas and apply them to the order chart and then say not only do I have the order chart kind of laid out, but I can then outsource it perhaps or automate it. And I have measurable goals for each piece of it. At that point you can start to actually give things to people who aren't as good as you may be. Whatever that means. But different pieces of your job and be able to check whether they're doing it well. That's the reason we can't let go of responsibility because we can't trust other people or systems, whatever it happens to be. Because we haven't actually thought about what makes each one of these pieces good versus not good. So you measure the results and you can do this just by yourself. And basically come up with like a continuous build system for yourself. Measuring the different important parts of what make you what you are. And what you end up with there is consistency. So for example, if you're ever in a place like Japan or Korea and you're feeling some culture shock, or you're just feeling like, you've walked from restaurant to restaurant, you can't find an English language menu and you can't speak Korean or Japanese and you ended up getting a plate full of some sort of meat because you just pointed at something and you were really hungry. Yes, that's right. It was a great time wasn't it? That was really kind of two or three years ago. Find the Starbucks. Because at Starbucks they have a system like this. Now I know people here don't like Starbucks, but whatever they can become. Because those of you who don't like Starbucks certainly like McDonald's. No, Starbucks has this kind of system in place. They have this kind of consistency. You can walk into a Starbucks in Japan and order the most ridiculous drink that you would do in the US. With all your stupid little stuff that you need on it and they will know what you're talking about and they'll give it to you. It will taste exactly as bad as it does in the United States. That's comfortable. So the last piece of this presentation is on offshoring. Offshore projects fail. They're totally worse than average. I've been part of them failing and it does seem like it's worse than average even from the end. The reason for that is that offshore developers suck. Right? Unlike me. But really, one thing I learned when I lived in India running an offshore development outsourcing group was that when you're in India or you're in the Philippines or wherever, the people in the United States are the offshore people and they suck in the exact same way that offshore developers in India suck when you're here. So it's actually not the developers usually. It's the distance, it's the communication, et cetera. They deliver low quality code but of course we don't know what that means. But that's an argument against it. So I was talking to Dave Hooper about this at the Software Craftsmanship North America Conference. We were riding a bus around getting sick in Chicago and he said, this is what we need to be asking. Not show me how to make it work, show me how to make it better. Name one time that has actually worked. And I said, well, okay, I'll tell you. Several times it actually worked. He's like, oh, okay. So I went to India. I wrote this book partially about my experiences there. Don't buy it, it's out of print. But you could buy it from someone else on eBay or something. I went to India to set up a software development outsourcing group. I did it because I was at the same company where I've been asked to come up with a list of steps for making great software. I decided that the list of steps should be I hire all the developers and then I create a culture that they can work with them that my trust will make good code. And the short version is it actually worked. So we had 350 people in Bangalore developing code, owning things, being real members of this extended team that was otherwise based in Louisville, Kentucky. The only problem is the people in India could not understand the people in Kentucky because people in Kentucky talk funny. So this could be a whole subject of some other talk that you wouldn't want to hear, but it can work. Years later I read this book, The Four-Hour Workweek by Tim Ferriss. A lot of people read this book and thought, well, what a bunch of bullshit that guy's too proud of himself, this is just malarkey crap. But I have been in India and I had seen an offshoring work and the idea behind Tim Ferriss's book is to outsource things that you do, outsource your life, and he likes extreme names, like you're only gonna work for four hours a week or whatever, he probably works 80 hours a week in reality. But I had seen the ideas from his book, Work and Software Development, so I got really excited about it and I actually tried an experiment in 2009 using, I think he recommended this book, the book service in the book, AskSunday.com. I started outsourcing stuff to low cost and virtual assistance. In this case, with Ask Sunday it was stuff like doctor's appointments, travel, research, purchases of things, for example, there was a woman in New Orleans that has these really awesome boots that my wife needs, so I took a picture of them and I sent it to AskSunday and had them look all over the internet and find the boots, so I thought, where do you get these things? And it was really good, like I went to the doctor when I normally wouldn't have. I went to the dentist and I got new glasses and that was the last time I did, but it was a very successful experiment. So then I went to the next level, Eric Simmers told me about this company, VMG DPO, they're based in Bangalore. They do more like business process outsourcing. So what I had them do was research stuff for technical talks, get pictures. I had a ton of books and CDs that I wanted to sell. So my first project was I just took pictures of my bookcases and CD cases and sent it to them and said, list all these on eBay for whatever price is appropriate for them and sell everything. And they did, and I got money that went in my PayPal account and I paid them through PayPal, so I kept them going for a while just by having them sell my stuff, which I wanted to do anyway. And it was like books that I would never pick up again, obviously all day, more. So there I am outsourcing, offshoring. I don't really even care where they are, I'm using the internet, I can call someone who wants to do that. And I was talking to a friend of mine, I helped start this company many years ago, and now, and decided not to be a part of it, unfortunately, and now they're very successful. It's a software development firm based in Bangalore, India, low touch. I was talking to this friend, I was about to start on the second edition of Rails recipes, and I said, I should just get some programmer to like report all of these recipes from the original book to Rails 3, and do a bunch of the work that I'm just dreading. How much would it cost for me to get an assistant with your company? And he said $10 an hour. So I thought, wow, I charge like $900 an hour. I could get someone for 10. I don't really charge $900, only $800, but I could get someone for 10. And I thought, wow, $10 an hour. What could they do that I could do at my high rate, whatever that happens to be? What could they do for $10 an hour that I was doing for a couple hundred maybe sometime? How do we define value in this case? Like if I do the thing that they could do, am I ripping you off really? That's not a good value to use me for something, when I could use them for something. So that made me think a lot. Holding that thought for a minute, in July of 2009 I got this email from Anthony Burns. And it says, last night it was a bunch of other stuff, you know, like love letter kind of stuff and emotional ideas, but last, here's the part that's important. Last night I realized this to some extent whilst I was sitting in a wonderful 90 degree heat that we call normal for 11 p.m. here, talking to the lizard that lives underneath the trailer I stay in. And this is not someone in Arkansas, this is someone that was emailing me from Iraq. So Anthony Burns, 32nd Infantry Brigade, he was learning rams and he started emailing me. And I thought, wow, it's kind of touched, you know, this is someone who is reading my stuff and I'm helping him and he's asking me questions. And I thought, okay, let's work together. I started sort of mentoring him. Here's the picture of him with his gun reading passionate programmer. So I thought, hey, let's do like an apprenticeship, but it'll be an offshore apprenticeship. So he'll be over there. It's not quite as far as in here, but it's close. And I'll be over here. I was in Colorado. And I had him start working on apps that I wanted that I didn't have time to do. I said, okay, here's what we're gonna do. You write these apps, I'm gonna be your customer. I'm gonna use the apps, but I'm also gonna review all the code. And I would make one little suggestion and the rest of the app would change based on that suggestion. It was amazing. And I could only talk to him, like, every other night, sometimes on IM, then he'd say, like, I won't be around for a few days because I'm going on a mission. I would worry, you know, I didn't know what he did. It turned out what he did was pretty scary, actually. So under those circumstances, it actually still worked, though. So he came back to the US, and he was going to go back and do whatever you do after you've gone to a deployment like that. Rather than that, we hired him at InfoEther as an intern. And then in the rest of us so much, we hired a full-time at InfoEther. And now he works full-time for me at LivingSocial. Since InfoEther has been acquired by LivingSocial. So what's the difference between offshore apprenticeship like this and offshore outsourcing? I think the differences are two. One is just your perception of whether or not it's going to possibly work. And when you offshore outsourcing, we just assume it's gonna suck and those people are no good. The other is our investment, our personal investment in it. In this case, I was moved by this young guy who was trying to learn, I mean, I would have been, even if I met him in a suburb in Colorado, that he was so passionate and he was protecting our country. But he was out there fighting for us. So it changed my opinion of how I should treat him and what kind of attention we should give to him. This is the Mechanical Turk. And Anthony Burns is nothing like the Mechanical Turk, but I think about this in terms of automation. We all believe that you should automate what you can. For programmers, it's built into us, it's ingrained. However, we don't believe in outsourcing or offshoring or hiring cheap labor. It's kind of funny because programmers, even the cheapest programmer is usually smarter than library B script. So maybe you can kind of think of outsourcing and delegation, whatever it happens to be, in terms of automation that's hard to actually do with a computer. This is Ken Auer, one of the early XP guys and last year at Software Craftsmanship North America where it happened to be. His talk was all about this, have cheap people do easy things under the close supervision of people who know the difference between easy and hard things. This is pretty interesting. Coming from someone who's so much of software craftsmanship or craftsmanship. So, in summary, I think we should think about defining what quality means before we start really talking about it and using it as a basis of our arguments. And to do that, you need to make fuzzy things as concrete as you can. You need to actually then measure them. Put systems in place so that you're not dependent on yourself or your colleagues being always on your or their A games. Always the best. Systems can help you and others. And then you start thinking about making that into a decomposed system that can then be farmed out to other people or to scripts or whatever happens to be automated. And you get consistency through repeatability. Consistency, you always hear this phrase, you can't cross a river using averages because it might be at your ankles at one level and then wave on your head somewhere else. This is the same thing with quality of work. If sometimes you're quality of bad ass and sometimes it's horrible, your customers will be left with horrible. That's the taste, that's the aftertaste. Take these ideas, automate and replicate them. And don't be so damn proud of yourself. Is it cost a lot of money? Probably could cost more than you do though, that's another talk later. And remember that automation doesn't have to be so strictly applied. So there's the story from Zend and the Art of Motorcycle maintenance, the South Indian monkey trap. Now I think it's actually bullshit but I'll tell it to you anyway. It illustrates an important point. Value rigidity. The people of South India devised a way of trapping annoying macaque monkeys. They look like this, they're terrifying, they steal your potato chips, take it from me. The idea is you dig a long hole and then you hollow out the bottom of it with a stick. So it's in the ground and then you pour rice down it. You put a fairly decent amount and you fill up that bottom section with it. You wait until the monkeys come along and they stick their arms down in the hole and they grab, they grab, they finally get a handful and then you come along with a club. And they're so fixated on keeping the rice that they won't pull their hands out of the hole. So then you just beat them to death slowly. That's value rigidity. You care too much about that thing. So I bring this up because as freedom fighters, as the people who were out here crusading for what's right in the world, for all of us who have been that guy or that woman who has been in a company trying to educate all the idiots on how to do software development right. It may be that we develop our own value rigidity like this. We might be grasping at rice and we might be actually holding on to bullshit that's not real. Maybe all these test frameworks and code quality, object orientation, node JS, cucumber and all this shit is just yak-shaking.