 So this is the fourth presentation I'm doing this week and it ties into with some of the others. If you didn't get a chance to see some of the others, I'll try to refer to some of the relevant details as we hit things. This is called a secret assumption of Agile because there's something that I realized after I was doing Agile for a while that actually, you know, the Kent Becks and the Ward Cunningham forgot to tell us when they started out. And one reason is that they seem to be successful and very obvious things for them but not so obvious for some of the rest of the engagements I've been in. So Agile overall is quite productive. I went through this case study a bit in one of my earlier presentations where we were at Nationwide Insurance. We had a traditional waterfall company, actually an Indian vendor. One of the best in the world at doing waterfall bidding for a project. And because the trial was a bit too long, they asked it to be bid Agile. And we bid an Agile project at basically half the cost, even though the labor rate was three times higher. So overall net effect is that the Agile process was almost six times more effective than the waterfall process. And this is, again, a waterfall process from one of the best, you know, level five waterfall companies in the world. And so this presentation is a little bit, what were we doing that gave us a six-fold productivity improvement over these traditional processes? So this basically is the kernel of this talk. It's what happens here. And the first thing that really is, this is almost a secret assumption of Agile, is you really have to be able to write code that's easy to change. And there's a style of programming that was sort of born with the Agile movement that we haven't necessarily captured as we've carried the Agile processes along. That we seem to be writing code in no other old-fashioned way, a little more of the waterfall way, under an Agile process and we're wondering why we don't get great results. And I think a lot of that has to do with being able to write code that changes. So I'll talk mostly about that. We'll get into a little bit of lean management and using processing power. But, you know, the key thing about that environment, the reason we were faster, was because we wrote code in a particular style. So this was kind of when I was trained, this is one of my early mentors when I was in IBM. I started in objects about this time frame. So I've been doing objects now about 25 years. And this was very profound. This was Rick Dina Telly, he actually worked for me at the time, and he said objects are only good for programs that change. And if you think about it very quickly, is every program that's interesting needs to change. And this is his way of saying that, oh, by the way, objects are really good for almost every interesting program. Now, there are also other techniques for doing programs that change. Functional programming has some techniques. I certainly have sort of systems like prologue for doing rules-based systems. There's other systems doing that. But objects are particularly good for programs that change. If it wasn't going to change, and then you know what it is up front, then, yeah, waterfall is perfectly efficient. And it's efficient as in the other process. The thing is with Agile, the first story you play is a virgin system. Every story after that is changing it. And so if you really play stories, as you're supposed to play stories, just pick it up blindly, pick it up the next story, work it, pick up the next story, work it, change the system, change the system, you get very, very good at changing your system. So the next wave of requirements come on when it's next release or sometime in the future, the system has been designed to make it easy to change. If for some reason your system is harder to change, the stories get later and later harder and harder to play, you have not designed your system to be ready for change. And systems I tend to work on, we tend to accelerate through the development process. We get faster and faster, we choose stories that are faster toward the end of projects than we do at the beginning of projects, partly because the programmers are getting better, partly because we're building on top of other changes we've already made. So sort of a question I ask in general, and we'll take time to ask it here, but I've asked this question sort of worldwide as I talk about this. Okay, here's your typical sort of Java function. And I ask the question, how many lines of code is in your average method? And as I've gone across the world, I hear things like, of course, you would never exceed the one page rule. That was an old rule we used to have. It says, all your code should fit on one page. Of course, I've seen methods that are thousands of lines of code, so they must have some really big pages. But, you know, you hear numbers like that. Some of them I say 10, and somebody says 15. Well, in this nationwide project we worked on, where we get the reference data, our average method size was 2.3 lines of executable code per method. And I'm not counting all this ceremony stuff, strip all this ceremony stuff off, but what you leave behind is 2.3 lines. So the depth statement associated with it didn't count that one, but the executable code, 2.3 lines per method. Tiny. This is not your typical programming style. When I look at existing code, as I go to various clients and open up their code, I don't find such tiny methods. Average class size was only 25 lines of executable code. I mean, that's kind of like the method size, right? Or you could get two methods. You get, you know, that'd be maybe two methods. Somebody has even half a method. But that's the entire number of executable lines of code in a class. It was only 25 lines of code. This is a different programming style. This is a programming style from Smalltalk. It was a style that Ward Cunningham used, and Kent Beck, and all his colleagues. It is how they allow the system to change. It's by writing very, very tiny parts. By the way, if you do this in Smalltalk, I have a colleague that has built some Smalltalk systems back then that average line of code is 1.1. In Ruby, I can get pretty close to this. Right now, I'm kind of, most of my Ruby project is running around between 1.5 and 1.8 lines on average per method. And that's because there's some stronger functional constructs. I think if you listen to Venkat's presentation about functional programming, those constructs already existed in Smalltalk in the 80s. And they were used explicitly, and that allows you to shrink your methods down even more. Very tiny methods. Some other statistics about that style of programming. In the nationwide, again, we were actually building a replacement application. They had a legacy application. The legacy application was written in Java, used an Oracle back-end for the database WebUI. Now, the new system used Java, Oracle, WebBase front-end. Same technology stack. These guys had 72 classes. They identified 72 classes as the application. This is an application for pension plans. Pension plans are relatively complicated because there are like five legal types of pension plans in the U.S. There's also different rules in each of the 50 states what they can do, and then there's like four or five or six agent models for selling these things. But they found 72 classes they teased out from this model. When our model had finished of the rewrite, we had found 1,400 classes. Different style of programming. This style of programming is tuned to be easy to change. We'll talk even more about that. So how do we do development in that cycle? So our life cycle in that project, you know, programmers' life kind of started this way. We started out with some sort of task and we needed to accomplish something. We needed to add to the system. We had spent some time doing design. People say we don't do design in an agile process. We do design. We think about what we want to do. And of course we prove we know what we do by writing that first test. So the great thing about writing that test, especially that first assertion, is that, yes, I can now specify I want a class here, I want to create it, I want to hear some parameters. If you really write the detailed statement, whether it's in Java or Ruby, or your other favorite language, if you write that test, you probably have a design in mind. Then of course we make the test work. And then we go back and write another test for something else. We still need to write all our tests up front. We write one, get it working. Write another one, get it working. We're learning as we go. Then, once you've finished all the possible tests you can think of, we can integrate this with all the rest of the code in the system. Make sure all the other automated tests run. And then we can go back and do it again. This is our little life. We're a little, basically, gerbils on a treadmill here. By the way, at any point in time, as far as we're concerned, once I've integrated and all the other tests have passed, if the client wants to ship this code, if somebody decides they want to ship this, we don't care. And that was a very powerful thing, especially in the early days of Agile, is saying, I, the programmers, are not going to decide when we need to ship. You, the customer, can decide it's always going to be in a shipable state or very, very close to it. You can decide when you want to ship. So, let's take a case study. I talked about this case a bit in my microservice architecture. This is actually the Stonehenge system I developed when we were here in Bangalore. It was a million lines of JTUE code. At that point in time, the largest Sun-certified job application in the world. 50 programmers were working on it. 40 here in Bangalore. 10 back in the States. We had 4,000 automated tests. So the question is, how long did it take my programmers to pick up a task, just pick up a task, do a design of a change to this one million lines of code, write tests to make sure that in fact all this stuff would work, write all the code to make all this test work for all this new functionality, check that code in and make sure every other of the 4,000 tests still runs, and you have no conflicts with the other 49 programmers. And they come back again. So how long does this cycle take? Well, again, I ask this question as I talk about this around the world. I get numbers like, well, I think it's a couple of months. Sometimes people say a couple of weeks or maybe in a really excessive day, maybe I can do it in 5 or 6 days. Well, again, using Java, and this was a few years ago, the average cycle time was 2.4, 2.5 hours to 4 hours or so. 2 to 4 hours to get through the cycle. Now, how can you go so fast with such a complicated thing? Well, first of all, we did have tests. Tests provide you a nice safety net so that you don't have to understand all the million lines of code. You just have to understand the parts you're changing. And you can sort of speculate that you do understand that until the tests prove you're wrong. So you can be quite aggressive in that. Also, think about 50 programmers trying to change the million lines of code. Somehow, in the next 2 hours, the chance of some other programmer changing the same code I'm changing is about 0. So the whole thing about 50 programmers is just furious data. It's almost irrelevant. The chance of having a conflict is almost 0. And, by the way, you're checking into the same path. So 2 to 4 hours. And, by the way, you get languages like into Ruby. My Ruby cycle time, typically my teams is more like half an hour going through the cycle. That's how fast we chew functionality up. Now, the key part of this is, in fact, the feedback you're getting. So, in fact, we have a goal that says, once I write a unit test, it needs to get running in the next 15 minutes. If it doesn't get running in the next 15 minutes, there's something wrong. You're trying to specialize something too hard. You don't understand the problem, whatever it may be. And a key role for your partner in pairing is to make sure you're sort of timing yourself on this. Maybe you're asserting something is too complicated to implement. Maybe because you try to get it to working, some place is not working so well. Well, then write a test against the part that seems to be hard. Throw that test away, write a different one. Well, we sort of meter ourselves on 15-minute cycles to get the test running. And then we write another one. So we kind of nibble at the problem till we get to the final big thing we're trying to get done. And if you nibble correctly, the last little piece is quite easy. Now, what if it's not easy? What if the code looks ugly after all this? That's actually a sign that your design may be ugly. Because when I'm talking about design, you should probably spend more than 15 minutes thinking about your design. Get yourself an idea of where you might want to start. Try it. Sitting there waving your hands with your partner, going to the whiteboard, drawing elaborate pictures, invoking architecture and other review boards, waste of time. If you got an idea of how it might work to the point where you could write a test for it, then write the code. It's a new feedback cycle. Ugly code means it must be a bad design. Throw it away, try again. You didn't waste a lot of time. It's only 15 minute cycles, maybe 30 minute cycles, maybe you spent a whole hour on the wrong path. That's not much time. The difference between a really good programmer in this system and sort of the average programmer is how fast they recognize the code is ugly. The tendency with less experience is once I've written that code and typed those little things in, little gold bars have come out the side somewhere and I couldn't throw those away because they're really valuable keystrokes. They're not that valuable. Throw them away, start again. So this is how we did the development. Now, these are some of the XP practices. This is back when there was only a dozen of them. I think there's more now. But I want to focus on one in particular, the one that's called Simple Design. Simple Design is probably the hardest route. Kent Beck sort of lays out what the rules are to have the Simple Design. He says, first of all, it has to work. Kind of a nice criteria. But it doesn't stop there, yet that's where a lot of our developers stop. It works. Let's check it in. Let's go get something else. Let's go to lunch. You have not finished at that point, says Kent. The code also has to communicate. In other words, it needs to scream out what it's doing. The variable names are going to be precise. The method names very crisp. If you feel the need to write a comment, there's something wrong with the code. Fix it. If there's a blank line in your code, and actually Neil Ford talked about this as well. If there's a blank line in your code, he's trying to tell me something. Tease that information back out. Make it communicate. You want the next guy to see this to be able to read it. Code is read 10 times more often than it's written. If it doesn't scream out its communication, the next generation has to look at this probably including yourself. No duplicate code. We don't like duplicate code. I have several things to maintain. I was in a client a few years ago, and they wanted to change one icon on an email. Well, it turns out there were six places in the code where that icon was actually specified. And another six places that they had to resend the email. It took them an entire day to find the 12 places. Another day to change the 12 places, and a third day to run the test to make sure all 12 places were covered. There should never been 12 places. Somebody decided, it works, check it in, copy it, check it in, check it in, check it in, and now they created a nightmare. So no duplicate code. And finally, throw away all that extra code. You got some code left over that may be useful in the future. Throw it away if you need it. If somebody has commented a block of code out, first thing I do is erase it. Obviously you don't need it to pass the test. Because guarantee somebody is going to stare at this and say, oh, should I uncomment and I should understand this, and oh, what a huge waste of time that becomes. But minimize how much code it takes. Don't give extra functions in a way that it's not been asked for. Don't give more public interfaces than it required. So you can go down to the bare minimum you can possibly get away with. Make as few promises to the rest of the world as you can get away with and move forward. That's the simplest design. Now actually if you follow these rules, and you follow these rules very precisely, particularly duplicate code. So how much code does it take to be duplicate? Well, I teach some of these things. We'll talk about some of the courses in a minute. And in my world, about half a line. There's a little formula here that you have somewhere else. I will tease it out. If you think about it, it's hard to write five or six line methods that don't have some part used somewhere else. It's really hard to write a big method. It's really hard to write a big class that doesn't have duplicate code in it. And you start teasing it out. So the code does shape the way it is with tiny methods and tiny classes because of this criteria. This criteria is not well understood and generally poorly followed. This is the secret assumption of Agile. The style of writing code that's driven by these practices and how rigorous you need to be. By the way, and originally because I thought simple design did not apply to test, it does. My original test on this sort of paradigm is that it's just test. Don't worry about it. Well, pretty much within a week I didn't understand my test because I had duplicate code, I had long methods, I had all of the other things that I described as bad habits. My tests were exhibiting them and I couldn't understand them anymore. It was like, of course, it's code. There's nothing special about it. It needs to be treated like any other code. So, a few years ago, quite a few years ago now, actually Refactoring came out with Martin Fowler. These are basically a set of patterns that you can take ugly code and turn it into pretty code. There's a lovely chapter written by Kent Beck about code smells. And then each of the code smells refers to certain patterns in the rest of the book that fix these code smells. This is a book about how to write small methods and how to pull code out. If you don't smell of this bad smell, you leave the bad code in place. Part of your training and part of your self-awareness needs to be, I understand every one of these smells. I smelled it. I have a very sensitive nose at this point. You need to develop that sensitive nose of these smells now how does Refactoring fit in? Well, Refactoring is the part that helps you do the simple design. Because once you get through the code and test cycle it guarantees that at this point it works because it passes all the tests but now I need to make sure it communicates and the code is gone and all the extra code is gone and you do that by some Refactoring tricks. You can do them with lots of points in the cycle but you definitely want to do them before you check it in. Don't check that code in and say, well, I cleaned it up some day. I'll make technical debt. I'll put a technical story in place to write the code pretty in some point in the future. No. You make it pretty today while you still understand it. It's not finished until it does these. Now, Martin Fowler sometimes talks about in his book, how do you explain Refactoring to your manager and your customer? And his very clear answer is you don't tell them about it, you idiot. You just do it. Would you ask permission to use an F statement or, you know, put a loop in your code? You wouldn't ask permission for those sorts of things. Why are you asking permission about Refactoring? It's because you don't want to do it yourself. You're being lazy today. Don't be lazy. Get it done. Then you don't have to have that discussion with that manager. There's also another book that came out a few years after that called Refactoring to Patterns. It talks about how do I take patterns and inject it into my code? Because patterns are one of the things that help solve a lot of these ugly code situations. They solve a lot of the code smells. But it actually, in terms of the cycle, it actually fits differently. Patterns don't come in at the end. Patterns you introduce at the beginning. When you look at your design and decide, ooh, I have some code over here and I've got a condition over here and I'm going to need to repeat that condition, you want to say, ooh, that's a state pattern. So you put the state pattern in before you add the new test to handle the case of the one case. And then it's easy to write the test that injects a second case. So it turns out patterns are injected after your design is done, that you see a need for a pattern coming up. And one of the things that's talked about in that book is one of the mistakes this guy made after he saw patterns was it was like, ooh, design is all about patterns and patterns were coming out here in this overly complicated design because it was about patterns. But he came to realize fairly quickly that patterns are things you discover the need for. You discover the need when you've got this design you want to change. And you look at the design change, it's like, oh, it's going to be ugly. Oh, maybe I need a pattern here. Pull out your patterns to see if you can find a match. Inject the pattern. Get all the old code working the same way it was with the new pattern injected. Make sure all those tests pass. Make sure you have a pattern to write the next test to add the new functionality. Again, patterns are one of these things that sometimes people try to inject at the other side of the cycle. It's much uglier to try to get it done there. It takes much longer. Oops, I'm going the wrong direction. Apologize. So, here's a case study. This, if you're in my presentation on microservice architecture, this is a case study from the pinball message example. We've been doing this application and we were measuring the complexity of our code because this was a very large client. They had an embedded organization that's doing software. We were brought in almost as an ad hoc group and it's called psychometric complexity or a McCabe complexity or some other things like that. It basically measures the number of branches in your methods. 100 is clearly a bad thing. I mean, evil at a high level. But there was a senior architect for the consulting firm for the primary contractor for doing software for this firm who basically said he's never seen anything less than a five. I mean, less than a five is just like unheard of. Systems with less than a five, you know, it's once in a lifetime event. He'd never seen that before. So, we were doing our development, using all our processes. Our McCabe complexity was 1.8. He almost had a heart attack. He says we can't be accomplishing anything with only a 1.8. Yet the system was running very nicely. And in fact, it ran so well. It ran so well. You basically, in a nine-week test cycle, you only found one bug in it. It only took two hours to fix. Versus, the other projects are spending all nine weeks finding and fixing bugs in just a frenzy of activity. We were sitting back, worrying about the next release, starting to write the code for the next release. Now, I think, actually, Neil Ford mentioned this as well. TDD tends to drive very small McCabe complexities. I think you actually deal with that. He's on record of saying that you show me your McCabe complexity. I can tell you where you're doing TDD or not. And again, following the simple design principles, you will get tiny methods. Tiny methods will not have tons and tons of if statements and lots of paths. Those will be teased out. Your complexity will drop. So, how do you get from, you know, where you are now to this, you know, proficiency associated with this particular model? Well, to some degree, the easiest way is basically to get some training on how to think about this way. Because there is a different way of thinking. And then you'll research, then you can use some experience. You should actually try it, because classroom learning is kind of nice at one level, but until you get your hands dirty and institutionalize these things in your head, you don't keep thinking about it. You want to have on your edge of your tip of your tongue all the little smells that it takes. You want to know how to fix all these smells. There is an alternative path. There is a team that does know how to do it. So you drop yourself into an existing team that has these practices, you will pick them up. But it's kind of like the dirt road compared to the highway. It's much more painful for you to get there. But it is successful. When I've gone back to organizations who basically, even teams I've worked with, where we didn't do the training, we just kind of did the dirt road trick. Almost to a man, the people that did not have that experience, they were like, I'm going to do this next time. Make sure you give the next guys the training. It is so much less pain. It will be so much more productive. In fact, here's an example. So this is a project I worked on where basically I was still in ThoughtWorks at the time and I was chartered to go as fast as I possibly could go. So no rules. And so in that environment, of course it's very dangerous. But you see that there's a little blue river fronting through there. You see this little zone here where it kind of starts out kind of nice. And then it flatlines. And then all of a sudden it takes back up running almost at a steeper slope. So what went on here? Well actually, we took time out in the middle to go through this training. We had an existing team. They were ThoughtWorkers. They were all experienced ThoughtWorkers. They've been writing code many years in many different client environments. Yet it was clear from the beginning of the project, working with them, they did not understand all these tricks and smells that we talked about. So we did 23 stories in the first 15 days, held the class for five days, and then we surged in productivity. In the next 12 days, shorter periods down, we got way more stories done. And in fact, this graph shows you very literally with the mathematics the benefit of the class. The payback period for taking that time off to do the class was 11 days. If you can do training and get the buyback for the entire class in only 11 days, of course you should be doing this training. Again, metrics from a real project, real payback periods. So what is this class? It's called the Object-Originate Bootcamp. It basically tries to teach you to think like an object programmer. In other words, like Rick DiNatelli told us originally, it's all about objects that are good for change. It is trying to get you to think like a programmer. This is one of the things that was said by one of the students in the class. This goes back to the Cape complexity guys. This is one of the lead designer, the best programmer on the client's side, across a very wide enterprise. He was a very bright guy, 20, 25 years of experience. He was in the class we taught there. This is what he said to the CTO or the CIO I think. The CIO of one of the major divisions. It says, 50 minutes after I got into this class I realized I know nothing about programming. Then I was a big exaggeration. He was a pretty good programmer. But the techniques that I was showing him and the way you attacked the program was completely alien to him. In 25 years of experience he never seen such crazy things in his life. And yet it was like, wow, it's obvious. Wow, it's obvious. So it is a different way of looking at a program even if you have lots of experience. Now the Obo Bootcamp actually goes back quite a ways. I think it was around between 95 and 97 when I developed this curriculum. And I did it because I was consultancy of one at the time. I'd be dropped into a client's side with ten programmers or so. They understand the domain. They're very bright programmers, but clueless about what objects are about. In order to make them productive we would go off in the corner for a couple of weeks and learn about objects and then model their actual application. So by the end of that two-week period we're starting to write code in this new style of fashion. So that's what it was for. It's basically to get real programmers up to work on real projects in real time. So far, since I've started this I've had over a thousand students go through this class in three different countries. I've done the class actually in these languages plus as well as the small talk. It's a very interesting class because this is what they use in law school, what they use in business schools. It basically means I'm sitting there as the instructor asking you questions and looking for your answer. Because I'm trying to make you think. I'm not telling you the answers. I'll give you exercises but I'll tell you the secret. You will struggle. And when I show you how easy the secret is, you'll think you're stupid. But it turns out with that methodology retention rates about 70%. Struggling to figure out the answer has higher retention rate. If I stood in front of the class and talked about it, retention rate is only 30%. This comes back to the effect of having lecturers stand up and tell you about these things, tell you about classes, tell you about objects. Most of it, not going to be remembered. Especially you don't get a chance to use it the next day. Most of the time I spend doing labs we're showing your code. There is the teach you to think like an object programmer in this environment. You'll teach yourself a language. In fact, we teach languages with this technique. You'll learn the programming language of your choice. It's pretty easy to do. It's a side effect. You'll learn the smells yourself because you experience them. You'll learn the correction techniques because you experience them. Most of the time you're going to teach yourself this by your mistakes. But at the end of it, you'll learn how you think about being a programmer. What I'm trying to do is, of course I believe in this model of apprentice, journeyman, and master. If you didn't see my other presentation, in my experience, apprentices, if they're ones, journeymen are twice as productive. And masters, 5 to 10x. Monsters at how much they can create. So this class is really more about masters are special. It's kind of hard to say what they're going to be. I can't train you to be a master. But, I can sort of get you from apprentice to journeyman. Usually it's about a 2 to 6 month period. You really focus on it. So in 2 to 6 months, I can double your productivity if you're starting out as an apprentice, especially with these particular techniques. These are foreign techniques to you, as it was in that program that I referenced. Then in 2 to 6 months, I can get you to being twice as productive. Master, much longer journey. Usually you will never become a master. It does require special skills, good conceptual skills, and a dedication to your craft. You can't decide after 2 or 3 years of programming you want to become a manager. You're probably not going to become a master at it then. But if you stick to it, it's there. The class is all about getting you from apprentice to journeyman. That is the focus of the class. Trying to get you that up, starting down that path to get to that double productivity. Continent of the class, it's actually taught in two parts. First part, we just hit basic concepts, but we reinforce these with labs. Yes, everybody knows about encapsulation. Very few people actually understand how to practice it. So we'll spend either 40 to 50 hours banging on these topics, running exercises that exploit this. Part 2, we actually introduced design patterns. Because patterns are, again, ways that fix a lot of code smells. And we hit, sort of, my favorite patterns, the ones I see and use most often. And then we briefly cover some of the others. Concerts are basically when you put patterns together in very unusual ways. So there's actually combinations of patterns that have their own names, but solve things. Again, another 40 or 50 hours. Now when I work with clients, I'll do part 1, and then we'll start writing some code. And until they have internalized some of the part 1 concepts, we don't hold part 2. At ThoughtWorks here in India, we started ThoughtWorks University around this curriculum. And we had Freshers, which you can completely abuse because they're used to being abused. And we put them through both sequential efforts with no rest. So we pushed all this stuff through them in sequential fashion. And being learning machines as they are in very bright people, they did absorb it. But in an industry, I tend to only do part 1. Wait a while until you feel like you've really mastered it. I'm one of the guys who understand part 1 and we have a part 2 class. Some examples of things about strange ways that we talk about. We talk about suspicious statements, things that are probably very suspicious. By suspicious, I don't mean wrong, just very likely wrong. Case statements. They're almost always wrong. Once every 18 months, I write a case statement. It's almost always because some idiot over there has passed me one means this, two means this, three means this across the interface. I need to convert that to something useful. Or something in a database like that. Some database wizard decided it was infinite wizard. One means this, B means this, Q means this, R, R means something else. Case statement. To convert that into something useful. But inside my model, you'll never see those case statements. Elts. Elts statement is almost always wrong as well. How many Elts statements do you have in your code? None? A lot. Yeah, a lot. We're currently developing a code in Man on Line. We've yet to write an Elts statement. We've been writing code for five months. We haven't used Elts yet. It's like go-to. It's kind of the go-to statement within the domain of this style of programming. Elts is kind of like the go-to. You get rid of it. Once you get rid of it, you figure out other ways to accomplish it, and you figure out other generations who used to write go-tos. I think about 17% of my lines of code were go-tos. And then some guy came and said, we're not going to use them anymore. And I'm like, dude, 17% of my code is go-to. How can I possibly live through this? Yes, there's some really weird structures I can put in place and all this other weird stuff, and yeah, I can write code this way, I guess, but where are my go-tos? It's just going to be horribly inefficient. Turns out it was a good idea to get rid of the go-tos. It's equally a good idea to get rid of the Elts. If statements. If statements are also suspicious. But the only place that if statement makes sense is it's in the first statement, it's a guard clause protecting the body from some bad parameters. So somebody says it's a bad parameter, throw them an exception and give them a different return code. That's what the if statements are for. You'll never see an if statement in line three or four. You'll probably never see one on line two because there's something wrong with your code. Fix it. Weird things. This is a different programming style. By the way, design patterns, how almost half the design patterns are there to kill if statements. Visitor pattern. Observer pattern. Composite pattern. These kill if statements. This is why you need to learn them. They fix this problem. Suspicious methods. Any method that starts with a word get or set or set probably violates encapsulation. Now, your tools, especially these Java tools, look, I can press this magic button and look, all my variables get getters and centers for free. I want to find that guy and shoot him. Look how easy it is to ruin encapsulation. Look, one button, encapsulation is completely violated. Because once you reach through and start grabbing these things, that's the death of your application. People reaching through grabbing data left-hand right, getting these things, getters and centers are evil. So we go through the class, we talk about this, we talk about remedies for this, how you avoid doing this, and we have exercises that really push the students to come up with conceptualizations and designs that don't require them. And the designs are elegant. The methods are tiny. If you have more than two levels of nesting, so you're looking at your code, just look at the shape of your code. Definitely wrong. Something's going on. Of course, it's got to be a relatively big method to have two levels of indentions, so you know it's going to be wrong for some other levels, but there's something that needs to be teased out if you have multiple levels of indentions. I use Sublime as my editor right now because it runs across all the platforms. Sublime has this lovely capability down one edge of the screen where it shows you the shape of the code and really tiny, tiny fonts. IntelliJ, I think, has the same capability. I'm going to turn it off because my classes are only like this long and this really kind of boring because it's always square. But you look at some other code, it's like, you know, the addition often almost goes off the screen and the methods, you know, the class is this long. That's what it's there for, is for the idiots to have to live with that code. If you need it, you have trouble. All right. There are also suspicious classes that we talk about. And one of the most profound ones ends in, E-R-O-O-R is probably wrong. It almost always guarantees it violates encapsulation. Oh, I'm the calculator class. I'm going to get your data from you and your data from you and I'm going to calculate it for you. I'm the calculator class. Of course, that means you're going to violate encapsulation, you're going to violate encapsulation and you're going to violate encapsulation. Or worse, I'm the manager class and I'm collecting all the information from all the good people doing all the work, all the objects doing the real work, collecting all their information and doing it for them. Taking credit for all their good work like good managers would do. So any class that is an E-R-O-R, very suspicious. Now, I guarantee if I open up your code and find one of these, I'll almost guarantee it's probably the biggest class in the bunch. It's the God class. Why is there a name with the word I in front of them? Because you really shouldn't tell outside the Java packages that it's an interface or not an interface. I know it's a C-sharp convention, I know it's a convention for Microsoft, it's really a bad idea. You don't want to know outside the world whether it's an interface or an abstract class or a concrete class. Those are not interesting things to know. Interface with only one implementation. Okay, that certainly violates extra code. I don't need the extra code for this. You only have one implementation to leave it there. When I have two or more, then define the interface. And actually, this is from my colleague Jeff Bae. I talked about him a couple of times. Jeff Bae feels like you have more than two instance variables in your class is wrong. If you have three instance variables, there's two of them that are more related than the other. That means there's a class you could probably pull out that has that job. Oh, look, I have a name and an address and a phone number. Well, it looks like this is contact information and this is the name. Separate the contact information to an array of contact information. There's almost no case that I could think of that Jeff talked about that doesn't apply. Now, where did my screen go? Oh, suspicious. Definitely going backwards now. So, suspicious classes, suspicious methods, suspicious statements. There's also suspicious data types and all sorts of other things. As you can imagine, this is a very traumatic class for an experienced programmer. But they can both get at the other end quite well. So, what are the results of this class? Well, basically, about 20% of the people don't get it. They just can't understand why you would ever do this. They can't believe it works. They can't even see a way to do this. They have no nose for smell. Their nose is completely burned out somewhere. They can't see a smell. These guys have trouble with conceptual thinking. It's not clear they really should be programmers. So, you know, about 20% of the people that can't survive the class. Some of the dropouts, by the way, are the really senior programmers who have been doing this so long and have such prestige in their position, they feel silly sitting next to a university graduate who's running rings around them. And almost just because of embarrassment, they drop the class. It's a shame because guys who have that level of experience, and especially architects, great conceptual thinking, they can't really understand the architects. Great conceptual thinkers. I love to take a conceptual thinker like an architect and retrain him to be a programmer. He's a beast. He has potential to become one of those master programmers. It's much easier to take one of those guys and teach him to be a programmer than to take your average programmer and turn him into a great conceptual thinker. That's almost impossible. Another 20% of the students come out of the class, started as a apprentice, come out of the class, they're already journeymen. We had a client who talked about the 15 minutes about understanding. He came out of the class, he was twice as good as when he walked in. Everything just clicked with him. He had enough experience where he was just instantly made sense. And that's very powerful. I had that effect also when you saw the graph with the training in the middle. I had some very bright programmers that once you show them these techniques, their productivity just soars at the other side of the class. Good predictions for success. If you have a background or a design background, by design I mean design of objects background, or even you're basically a polyglot relative to languages. You know more than one programming language. These are guys who almost always succeed in the class. If you only see one language in your life and it's COBOL, yeah, it's not a good indicator. Your chances of survival are much lower than these guys. The key is this knowledge that you're being imparted. This is very strange stuff. If you don't practice it almost immediately, you will lose it. Even with Socratic Methods being taught, you'll lose it. Yeah, a few months from now you'll think about, oh, I remember that. Ours are bad, but I can't remember why. I don't know how to fix it. And, oh, well, I can't remember that. Let's keep going. Knowledge is lost. So we're not going to apply this. Don't take a class. So most cases where we're doing this class is because we're going to drop these programs into a delivery engagement using these techniques immediately. In this class, unless you happen to be one of these guys that made the leap to journeymen already, you need to be pairing with somebody who does understand this stuff, a journeyman or a master. Two guys out of the class, still apprentices, pairing together, they're just going to struggle and get frustrated. It's like, oh, I can't figure out how to do this, I can't figure out how to do this, and they walk home frustrated. I mean, programmers don't come into work every day saying, gee, today I want to write some bugs. Why does it happen? They're going to break downs. Process break downs. So you put two apprentices together, they're not going to get anything accomplished. In fact, maybe they hurt you, and they're going to go home not feeling good about themselves. You pair this apprentice with a journeyman, they write some real code that day, and he goes home happy. And he wants to come back in tomorrow and do it again. There's a huge morale impact to not doing this correctly. All right, what about maintenance of such systems? This goes back to the 1400 classes of nationwide. So we did... I worked with ThoughtWorks at the time. We did three releases for this project, and then we walked out the door. We had client programmers participating as we went, and the client programmers were responsible for continuing the upgrade and maintenance of this application. In fact, they put three more releases out after we left. So the question was, what did it take to transition the knowledge back to these guys? This was their answer. The people on the team. They said, we need no documentation, we need no training, and we need no time to transition it. And there was no problem. They were successfully delivering the next release and the next release. Why? First of all, they received the ideas. They were pairing. They rotated across all the components. There was no part of that system that one of the client programmers did not understand well. There were about two or three of them. Now, the managers just couldn't believe this. The project owners and the VP said, there has to be some transition. You have to write some documentation. We kept saying, you know, tell us what you need. We'd be happy to do it. So we don't need anything. And they successfully delivered after that. Again, they're steeped in this, the 1400 classes. How can you possibly not need documentation for 14? How can they know what they do? Each class is small. And the only thing if the system's not behaving is one guy not behaving. It's easy to pin it down. Debugging the system was very easy. The average time to fix a bug in this system, I quoted this the other day, average time to fix a bug in this system, 15 minutes. We didn't even bother writing them down or recording them to date. We just fixed it, 15 minutes. This is a very, very easy way to change the system if you follow these guidelines. Now, this is still valuable in engagements I'm in now. So I'm right now working for the mail online at least four days a week. And we're doing this. So we started training them as I started the engagement. We're taking the programmers and putting them through object-oriented boot camp. Same boot camp we talked about all the way back almost to the late 90s. First class was held 1st of October, which is a month after I started. We've had about 9 to 12 students in this class. We've run four sessions so far. Every programmer, every project manager, every QA has been through this class. Because we're practicing anarchy and they're only developers in this world. There are no BAs in here because actually the client does not have BAs. We're doing... Newspaper publishing is not that complicated a domain. We're putting web pages up. So the BA is not a required role in this domain. We're putting everybody through this training program. Absolutely. Most project managers had computer science degrees. Most project managers actually were writing code at one point in their careers. They got great leadership skills. They understand the big picture. Again, if I could retrain them into programmers, I got a beast. My colleague who is here with me this week, Julia Hayward, she's a project manager. She went through boot camp, the first boot camp. She's participating in the project as part of the anarchist. She can tell you how much more fun she has now than she used to have. Now, a lot of the QAs, they have difficulty. Yes. We do give them the option to continue working in their old role on some of the legacy code. They're not forced to come into the new world. But we've given everybody the opportunity to do this. Implementation. So now we start using techniques. So we actually started development after the class ended after two weeks. We dropped the first set of developers at a table and said, let's start building something. And we gave them a very complex web page with all sorts of statistics on it that they needed to build. There weren't stories being written or anything else. They were doing this in Ruby. Ruby was the language we introduced them to in boot camp. They'd never seen Ruby before that. So two weeks after seeing Ruby for the first time, they were writing production in Ruby. And within a few weeks after that, they were actually beginning to deploy the first versions into the cloud. Remember, they have already deployed a version that they're beginning to show the client saying, this is what I think you need. We're almost finished. Class is very effective. Again, bright programmers, bright tools, bright environment, very productive. So where we are right now, again, we run four classes at this point. I now have five independent tables running. Each table is working on some major feature associated with our site needs that are running very independent of each other. Some of them are using even different processes. They interact with their clients in different ways. And it's perfectly fine. But they've all been seeped in the same sort of group work, understanding how to write great code. The only thing we ask of these groups to do is, does native speaker. Not the manager, not the leader. It just does native speakers so that a spokesperson can speak for the table. So we can ask about how things are going. Do you have resource needs? Do you have a project to the table? And that's working very, very well. We've gone from being able to turn out a product maybe once every six to nine months for a typical project to getting something done within two months that people have used never used that particular language. The productivity boost has been enormous. There is a different way of writing programs. The agile guys, when they started the agile stuff, forgot to tell us there's a different way of writing programs. They knew it. They felt comfortable with it. They just forgot to write it down. And as I was going through my pain across five or six years trying to become a good object programmer, I finally ran across this knowledge and somebody was on one of those teams and he began to ground me in this stuff. But across five very painful years I finally learned how to do this. And what I have done now is take that five years of pain and cram it into two weeks of extreme pain called boot camp. By the way, the name came from the first talk. They named it boot camp. It wasn't my idea. But it sort of gives the right sense for it. Well, that's kind of the story. That is the secret assumption of agile. There is a different way of writing programs they haven't told you about. It makes it easy to change your application. I think I have a little time for questions. Any questions? Sorry? I don't run boot camps except for people I work with and deliver code around. Because I would rather write code. I think ThoughtWorks will offer these classes for people who like it. This is part of ThoughtWorks University now. I do know that ThoughtWorks does on occasion sell this training as well. It does take a master object programmer to teach it. You can't teach this by just reading a script and showing slides. You teach it by writing code and listening to what the students are doing. So you have to be basically a master object programmer. Any other questions? Am I going to write a book? I hope not. All the guys that talk about writing books talk about how painful it is. Everybody says in past tense, I'm glad I wrote a book but it's always in past tense. I'm too old to try to go through that pain at this point. I think it would kill me. I'm thinking about putting videos together. Because apparently now you can go to a publisher like Addison Wesley, spend a day and get an hour long video out of it. And they're beginning to publish those as entities. But this again, this is a karate method. It's going to be hard to sort of ask questions of a client through a video or from a book. I would recommend refactoring if you haven't read it, looking at the code smells and then chasing down these code smell how to fix it. Great place to start. There's a Kent Beck book called Small Talk Best Practice Patterns that's even denser about this stuff. There's been a rewrite of that. It says it's called Implementation Patterns by Kent Beck. It's been updated to use Java or Ruby. So again, it's a lot of the secret software is being written down by those guys. So if you're looking for a book, refactoring Implementation Patterns by Kent Beck, those are some pretty good sources. Well, yes. I've had any experience in the embedded world. The first two agile projects I did with these techniques were embedded systems. The first bug we found when we put the embedded system together with my software, hardware bugs. Twice in a row, first bug was a hardware bug. The code was perfect. Now, there were bugs in the code eventually we found, but the first bug in two cases, one was an embedded controller for a giant tape library, the other one controls the valves on the Alaska pipeline. Two of my first two agile products were embedded systems. Taught this class to them. In fact, the class was designed for those guys originally. Embedded systems absolutely works perfectly. All right. Thank you very much. I enjoyed...