 Welcome everyone. Thanks for joining in. Good morning, good evening, good night depending on where you are from. We have with us James Greening. For those of you who are probably already familiar and which is why you're here, James was one of the original Agile manifesto signatory. He's been a very strong proponent. The way I relate to James is two things. One is the all the awesome work he's been doing in pushing the envelope on TDD in embedded systems. I think that's really his core forte in my opinion. The reason I would really know. And the second reason that is not very well known but certainly worthwhile mentioning is he was the original inventor or creator of Planning Poker which a lot of people have used, abused and I think James has moved on. He's found other techniques which are equally inaccurate as he says. But yeah, I think that's faster. So great. I think without further delay I want to hand it over to James. James, if you don't mind sharing your screen. Okay, I'll share that in one second. I do happen to have a replica of the original Planning Poker card deck right here which of course as an extreme programming enthusiast we always have note cards handy. Awesome. I could send stacks of these the replica decks to everybody around the world. Anyway, let's start the presentation. Hello everybody. It is an honor to be here with you. And I've got a topic I'd like to talk about. It's a topic for a thank you for the thumbs up. I appreciate that. I'm gonna hopefully see some of those during my talk. Very good. All right. It's good. Is it can you do the other symbol too? Can you do thumbs down or good? I'm glad that's not possible. All right. Oh there's a we can wave as well. Okay very good. So technical excellence. This talk is for if you're a developer and you don't know why you should care about the technical practices of extreme programming. This talk could help you if you're a business person and you're wondering if you're getting tired of your team telling them telling you you can't release a product because you've still got some bugs. Maybe you're interested in this. If you're finding it's hard to get things done at the time when we want to release. Maybe you'll be interested in this too. So technical excellence you need is the title of my talk. I'll see if I can work all this technology here. And sure enough I can. I'll tell you just a little bit about me because you can tell by looking at me. I've been doing this for a while but when I went to high school one of the guys I would be one of my friends growing up was programming in high school and he was trying to get me excited about it. He showed me his punch cards. He showed me the tele the punch machine. He showed me the room with the no windows and a raised floor and I thought stay away from that. This is not going to be anything I'm gonna like. And then in university I'm studying calculus as part of engineering and we had to solve the problem of calculating the area under a curve. And if you've studied physics, I'm sorry if you've studied calculus, you know what Newton did to discover calculus was he kept making these rectangles smaller and smaller. And so we had to simulate that in a computer and I found out it was fun in that someone would actually pay me to do this thing. And that was kind of a shock to me because it's like it's solving a puzzle I could do that and someone could pay me. Okay, I think I'll do the same. My first job had to do with embedded systems. We had kind of primitive tools in the day and I'm telling you this not to because I think you care about my history. I'm telling you this will be a point I'll bring it all back together later. But you know, booting up this computer meant keying in the right binary sequence. And you know, I didn't actually ever do that successfully. I make too many mistakes for that. But the guy I worked with could do it pretty reliably. So he was a guy that would boot up the computer. Pretty primitive tools. And of course, things went wrong. And if you had to erase your program, you see the little windows there and those in that in these chips, you shine ultraviolet light in those to erase the program so you can reprogram the device. This is kind of a long feedback cycle. Something that we don't really want to have as long feedback cycle. And we had tools and things primitive things logic analyzers in the oscilloscopes to find out what our code is doing. We would have loved to have had a serial port. I think, after a couple years, we did get a serial port just for debugging. And but it was a it was a rarity to have the hardware to be able to actually just dedicate it to something like debugging me, why are you going to write bugs? We didn't know the other way. Source level debugging was assembler. So there's a little bit about what the technology was like, when I got started in 1979, you'll see that number come back and you'll know why I mentioned this later. Now, about 20 years into my career, I was working with Bob Martin, who I've known for most of my career. And we were interested in learning extreme programming. And we made an arrangement with Kent Beck and Ron Jeffries, Martin Fowler and Ward Cunningham to come and teach us and we could teach people together. And that's how I bumped into extreme programming. It kind of changed my life because what I thought before then was the way you write code is you write some bugs and then you go fix some later. That was the way to do it. But extreme programming showed a different way of doing it, which was very, well, would it really work was one of the things I was wondering about. And I think it would really help with embedded systems. But that's a different talk. So here's Bob in 2001 almost, almost 20 years ago now. And he says, James, would you like to go to the lightweight method summit in snowboard Utah? And I don't know if you know about snowboard Utah, it's half a world away from you. But snowboard Utah is where one of the best ski resorts in the world is, certainly with the best snow in the world. And of course, what I thought was sure, Bob, I think I could make it. I'm learning from these guys that we're going to go to this meeting from lightweight methods. What's that you're saying? I thought you were part of the edge of Manifesto. And yeah, but the name before the edge of Manifesto meeting was what we were fighting at the time were heavyweight methods. And what we were trying to do was something lighter. And so we called it lightweight methods. And then right away in the meeting, I'm pretty sure it was word that said it was, we need a better name because he wants to be known as a lightweight. And so somehow agile came out of that. But one of the things that was of the time is this book by Humphries. And maybe we misunderstood it, managing the software development process. But what it was leading to was doing the interesting work, the design work, you know, in the United States, and then emailing that was their email, somehow getting that the requirements to places where lower cost programmers might live. I'm glad to see you guys are thriving, thriving programming community in India. And then, you know, that skill that didn't matter, you know, we could send across the world, as it turned out, that skill really matters, plug replaceable programming units, Watts was talking about, if you had a better process, the people wouldn't matter. Now, I'm not sure if that's exactly what Watts meant. I'm not sure if he actually meant that, but that was the message the industry got. If the process was better, the people wouldn't matter. And now we get to the edge of manifesto meeting. And well, let's see what was happening at the time, defects, delays, frustration, late projects, death marches, you know, a lot of the same stuff we have today, just different. Here's this edge of manifesto thing, which we thought pretty much no one would care about it. After the meeting. And some of you guys care about it. So people care about it. Now it's kind of interesting. We didn't think it would really change anything. We had no intent no idea of that. But the first bullet point is kind of interesting, because I thought extreme programming was an improved way, an improved way of working and improved process, improved techniques, right? That's how I was thinking. And everybody in the room is talking about individuals and interactions. And this is kind of strange to me that they were putting the people on the front side of this, because I was thinking, if people did extreme programming, things would be a lot better. But they're talking about, you know, no, people don't, you know, you put good people together and other do good things. And this is like, oh, but I'm an engineer. It's like, no, let's solve problems for this people stuff. You know, that makes us engineers kind of uncomfortable. So that's a little bit about the my roots here. Oh, also, there was a first scrum class ever was held at our office at Bob Martin's office in the Chicago suburbs in 2003. And here's some of the people that attended that course. Now, this is kind of interesting. The scrum kind of has taken off, right? There's all these people who are called scrum masters now, unless they're changing their name to a more politically correct name these days, I don't know. But I don't care about, I mean, this is they're the master of the scrum. Okay, so 300,000 of them. Okay, and so what scrum supposed to do can it's been become amazingly popular. I bet some of you are scrum masters there. Let me see some thumbs if there's any scrum masters there thumbs up. Alright, there are some and then there's people that are participating in scrum teams, right? So what's scrum supposed to be? Let's see what Ken says it's supposed to be scrum exposes every inadequacy and dysfunction within an organization's product and systems development practices. The intention of scrum is to make them transparent your problems. So you can fix them. Oh, it's problem solving. All right. Now, in the 80s, we were doing this thing, TQM total quality management. Every 10 years, by the way, TQM gets rebranded into a different thing. Now I think it's called lean six sigma and I'm not sure what'll be called next. But the names keep changing. But the basic core is the same structured problem solving. Now scrum is like structured problem solving in its definition. Although kind of what I see most of the world doing is not a problem solving loop, but a doing loop. Let's do scrum. And they keep doing scrum, whether it makes any sense or not, or they're playing planning poker, whether it's solving their problem or not. So I'm seeing too much of the do cycle. I didn't see any thumbs go up there. So your people are wondering now. So we still have problems, but nobody's saying nobody's seeing what's the visibility? What are we trying to find here? I'm finding that there's a lot of in agile. There's a lot of people following the dogma, and less people solving the problems. And I'd like to change that. I'd like to see us having more problem solvers, and less dogma followers. If we're going to do something, why are we doing what problem we're trying to solve? If we put the problem in front of people, then we have a chance of solving it. I picked up this book a number of years ago, in preparation to this talk, I've, you know, I've kind of been interested in aviation. My father was a World War Two fighter pilot, and that's he was a wingman in an important battle during World War Two. And that was the source of the name of my company. And I know the military does a lot in debriefing. So I picked up this book to find out about debriefing. And the person who's writing the book is a fighter pilot. And he went from copy machine salesman to fighter pilot in two years, with no aviation experience, because he could take feedback and make changes and improve. Okay, so here's a pilot coming in to fill up their aircraft. And the way that this is designed, you can see that umbilical there is going to be flopping around in the wind. And the plane's got to fly in and plug into it. This is very stressful. If you're in a battle situation, as I understand it from reading the book, I don't know have no first hand knowledge here, very stressful situation to be in. And so they wanted to problem solve this. And they came up with a solution, which was have the fighter pilot come in flying formation with the tanker and let the pilot take a break because this is a more relaxing thing to do than trying to fly into a pinpoint in the sky. They can fly in formation and leave the boom operator up to filling the aircraft back up with fuel so you can get back to business with the enemy. All right, so this is interesting problem solving real problem solving they actually found a problem and solved it. So Ken, how are people doing it solving their problems? How do we think we're doing it solving our problems? I read a an article in what was this in David Dunning in smart planet. He surveyed engineers to see where they thought their skills were. And it says here I'll just pick through some of the numbers 32% of the engineers. Wait, let's see, company a 32% of the engineers thought they were in the top 5% of skill. And the company B, you know, you think it's lonely at the top, go to company B, 42% think that they're in the top 5%. Hmm, what does this mean? Interesting. Well, it means that a bunch of people are wrong. 40% think they're in the top five. That means 87.5% of them are wrong. I know my math doesn't quite work out but it's more about Are we thinking about this right? Why do we what is the skill acquisition model? Maybe you're familiar with this drive the skill acquisition model. There's a progression of skill growing that we can go through from novice to advanced beginner to competent to proficient to expert. And you know, we could march along there. And you know, so in that study, a lot of people thought they were up there at that expert area. But where were they really? If you have an aptitude for something in this a friend of mine wrote this article, actually, it's only an E friend only an E friend, we've never met in person. But we've met to but have not gotten around to it yet. He wrote this article, and it's really spoke to me. But he said he was trying to learn American bowling. And he had an aptitude for American bowling and got pretty good really fast. But he plateaued. He couldn't get any better. And then when he started to get some help, he found out he had some of the fundamentals wrong. He wrote this article about this happening to developers. And he calls it the expert beginner. So imagine that you're working and the way most of us developers work is by ourselves. So we don't have any feedback. And if we were to produce something that was useful, and that made money for our company, your company is going to praise you. And you will have accomplished something important. But you might have done it in a way that isn't as good as it could be. One of the things I like to think of in this. So if you were able to advance and produce this application, you would get the in your only ever seeing your own work, you would get this idea that you're an expert. Now, for me, I kind of think of this now after looking at a lot of code. Getting something to work is not easy. Alright, so I think, though, it's the aptitude test for programming, if you can get the app to work, right, that's the aptitude test for programming, then you might be able to grow the skills to really be a professional programmer. And there's a lot to know. But if you can't get an app to work, you probably don't have the aptitude. So how we doing? Okay, I'm going to continue on this thread of how we're doing as an industry. And there was an invitation again, 10 years ago, about to go to the agile manifesto, 10 year reunion. And a number of people went there and there was an agenda. Oh, it gets where it was snowbird. And that means they're skiing. So of course, I had to go. And it was an interesting group of people that were invited some of the original people from the agile manifesto were there and some others that are involved in the community are there. It was a great meeting. We wanted to explore and come up with guess what, for bullet points. And what's wrong with agile? What do we need to do with agile? And we what do we how do we have to fix agile? Because we kind of thought it was broken. And I think it still is somewhat broken. Although, of course, there's places where really good things are happening. There's a lot of places where not the right things are happening. So here's this group, it was a structured medium, like the first one. And we did come up with four bullet points of which I remember two of them. Because they're the two that I actually cared about. The other ones, you know, were also runs demand technical excellence. If we want to get good in our industry, we really got to take the quality of our products, and the way we work, we got to keep improving that. And how are we going to do that by helping people change, helping promote change, that means we have to find ways ourselves to change and help people change how they work. My business is about helping people learn test driven development. And it's been quite an interesting journey to find out ways to help people learn that. And I can't convince you about test driven development, about it being a good idea or not. I can give you an experience of where you might convince yourself. This is kind of what I've discovered in my applying of these two things here. But how are we doing? Excuse me, I'm a little thirsty here. It's late as well. So Ken said, right, we're going to fix problems. But what's happening, Ken? Well, unfortunately, many organizations change scrum to accommodate their inadequacies or dysfunctions instead of solving them. Now, I can read this and think Ken is saying don't change scrum. But I don't think that's what Ken means. I think Ken means give scrum a try. Now, when you get to retrospectives, you have to do serious problem solving. And then you have to solve problems. You can't just be like the three monkeys in the earlier diagram where one's not looking, one's not saying one doesn't want to hear anyway. You know, see no speak no evil. And today, we still have these problems, although I think we're making a lot of progress. So here is scrum. Actually, this is extreme, this is whatever iterating. Okay, I don't use the s word, I'll tell you why in a little while, iteration, iteration and hardening. What's this hardening thing about? You know, if you start doing scrum and you want to release after several iterations, but you don't have a good automation in place, you've got to go do all your tests. And so here we are at the bottom of the waterfall. There I am. It's kind of a nice peaceful bottom to the waterfall. And I'm down there looking around for bugs. It's kind of wet. But it seems like not too bad of a place to be is that what it's like at the bottom of the waterfall? Or is it more like this? You know, you've used up all the time, the pressure is on. No, you don't have many options. And you just got to take your lumps. And we just got to trudge through it. That's we're getting crushed at the bottom of the waterfall. So what happens at the end of these iterations before you're about to release your product? See, there's some little fires popping up here in the feed. And now, you know, that would be great because we had the hardening sprint to find the bugs. Right now. And then somebody says, you know, there's just one more bug. Oh, and that's when it gets kind of interesting when somebody says there's one more bug. And then one more bug after that. And oh, my gosh. Oh, the fire. How does this happen? Why does it happen? I know, it's somebody else's fault. Oh, wait, no, it's our fault. Oh, we, you know, we probably have to take some responsibility here for this because we did make the mess and we I know was here before. But okay, so here is managing bugs. This is the bugzilla website process that I pulled about 10 years ago as an example here. I don't want to be good at this. Now, are there any developers in the room? Can you developers do a thumbs up here? I need you all in the virtual room. I need you all to stand up. Now, if you don't want to live a life of bug hunting, you have to admit there's a problem. And the problem is you. All right, I'm a programmer and I write bugs. Everybody can give a thumbs up if you're saying you're right now yourself. I'm a programmer and I write bugs. Come on, more of you. All right, this thumbs up thing is pretty cool. All right, okay, there's a chance for you. Okay, all right, okay. No gnashing of your teeth anymore. Okay, let's move on. So technical excellence, what is it getting the app to work? chasing down the bugs? Well, you got to know how to do that. But that's not technical excellence. Now, one of the biggest problems, according to Jeff Sullivan, the other one of the other scrum founders is that people can't get a shapeable product. So one of the really cool things that's going on right now is DevOps, which as far as a guy like me that came up through extreme programming, things looking at that as well, yeah, that's extreme programming taken to its conclusion. You got to automate your pipeline. Actually, there are people doing that back in 1999, where they actually in a hardware software environment, was a machine that I wrote, I have a friend contribute a story to my book about it. It was a machine that processed potatoes and turned them into french fries. You know, basically truckloads of potatoes got dumped into this machine. It was all automated. And at any rate, they had a continuous build pipeline back in 1999, the logical conclusion of extreme programming. But you know, so people aren't getting it done, they're doing the do cycle, they're doing, they're doing scrum, they're not solving their problems. They're worried about the deadlines. Yeah, of course, the business lives on deadlines. We've got to make deadlines that they're important. What we want to do is have the most pop the best possible thing for the deadline, right, not an arbitrary deadline, a meaningful deadline, and we'll deliver the best value we can by that point. Now, when you adopted scrum, did engineering change how they do engineering, incremental management and planning without incremental engineering skills is a recipe for pain. And I've seen a lot of pain around this, right, we start iterating. And the people that are supposed to do the delivery are not used to working iteratively. So it's painful, they feel like they're doing poor work. And so I'm going to propose in a, I'll propose a marriage. I'm not the first one to propose a marriage like this, the marriage of extreme programming and scrum. Alright, so scrum has the planning practices that have been popularized. Extreme programming has the technical practices that can make you successful at scrum. And actually, the scrum alliance started doing something about this a few years ago, what 2014, there were some certified scrum developers, are there certified scrum developers in the audience? All right, well, the metrics are working out just fine here for me. So here we are back in 2014, there's updated numbers, I didn't get them. But it's well over a million scrum masters now. So 300 and some 1000 scrum masters and 50 some 1000 scrum developers. What does this tell you? This tells you it takes six scrum masters to master one scrum developer, obviously, by that ratio, what else could it mean? Now, somebody goes off to scrum master school. Come on, you can give me a few more thumbs up on that one. That was like one of my best jokes ever. Okay, so maybe it wasn't okay. Okay, you guys are kind. All right, I've heard that about this. So somebody goes off to off to scrum master school and comes back, inserts all these micro management techniques is what the developers are thinking, right? They're being micro managed now. They don't like it. They don't understand it. They're not sure how to work in this environment. They're being asked to sprint, which means go full blast as much as you can. Oh, sprint, I'm sorry, I told you I wasn't going to use that word. But this is why I don't use it. It's a wrong metaphor. Right? Well, look at what happens to the sprinters. They gave it everything they collapsed. And now your scrum master comes over your product owner comes over and helps you back to your feet gives you some oxygen so you can do it again. This is not really what we want to do. We have to find a sustainable pace. Right? It's not doing anyone any good by overloading this vehicle. Right? It doesn't have the capacity to take on that workload. And we're wondering why things don't end so well. So maybe we're not doing as good at bringing the agile ideas into development. Here's a typical rant on here's one on Quora back from about five years ago, four years ago. It popped up in my feed. You know, why do developers dislike agile? And so I read this article and I was filled with misconception. So I wrote an article about, you know, what they got wrong. But and then my article, at the time when I took this snapshot, I got, you know, a few hundred upvotes and a couple hundred or 100,000 views, which is like I was shocked that anybody cared about what I had to say there. Here's some guy he got half a million views and 3,600 upvotes because he hates agile. And his story is 100% true and 100% not agile. He just doesn't know what it is. He's being iteratively managed, but he doesn't know iterative engineering. And so I was out to dinner with some people once in Chicago, not too long ago. And I was talking to them and they were talking about their agile. I said, Yeah, people do the easy half of agile. They don't do the hard half of agile. And he said, Well, what's the hard half of agile? I said the technical practices. Yeah, of course, I'm saying the technical practice. He goes, No, it's not the hard half of agile. The hard half of agile is the people. It's like, Oh, gosh, a truer statement. It happens. And that's been said. It's like, I'm thinking there's two halves to agile and there's three. Oh, no, move over iterative planning and technical excellence. We got to make room for respect for people. Okay, so respect for people. This is missing. And actually, if you're asking people to iterate and you haven't given them the skills to do it successfully, haven't helped them learn those skills, this is a recipe for disaster. Or at least a recipe for pain. So here's this debrief. I did a little debrief with the people I work with whenever I'm doing a training class. Looks like we got about 10 minutes left. So I probably have to pick this up a little bit. And in my training class, I asked them how much time do they spend debugging? And how much time do they spend coding? And it's kind of interesting that there's a wide range. Usually the guy that brought me in is a guy who's not having to debug so much. And everybody else is spending a lot of their time debugging. And a lot of people live with really long build cycles. So if you're trying to keep your mind focused on your work, and all of a sudden you got to wait five minutes to get feedback on your code, guess where your brain goes? It doesn't stay in the work, you got to restart. You know, how do you test your code? I asked them, and people are using log messages and print outs, and sitting around waiting for the manuals, you know, to run their manual tests and single stepping through their code. And you know, running it in the debugger, right? Every time you code, you have to use a debugger. Otherwise, how do you know it works, right? This is status quo. A lot of the tools are the same tools that I used in 1979. A lot of the techniques, the same techniques. So I'd like to congratulate all the developers using those 1979 development techniques. When we've learned a lot since then, right? I wish we I wish more people knew about it though debug later programming is what we learned is what you all that our programmers learned is debug later programming. What is debug later programming? Your program will have bugs. And they will surprise you when you find them. So what John Gall tells us, from the systems Bible, really good read, I really recommend it. So here, this team is celebrating their release, having killed 1293 bugs. A bug comes and spoils the party. And the lead developer hacks a bug. I mean, engineers a solution to the defect. And now they're getting ready to go back to their party. And they don't even know they're surrounded, totally surrounded. Oh, no, what are we getting? They don't know, they're back into great, a blissful ignorance. Where do these bugs come from? You know, we can't blame anybody else. We got to take responsibility. Responsibility. No, we can't blame anybody else, we have to take responsibility. Okay, because when you do development, followed by test, you're going to find defects, you're just not going to find all of them. I'm a programmer and I write bugs. Okay, got to hit some humility here. It's not our fault. Yes, it is. We put them there. So what is the impact of debug later programming? Now, if you're interested in getting your team started with test driven development, you have to understand what they're doing right now, debug later programming, you have to recognize it's a problem. People make mistakes. Now they don't realize they make mistakes because the feedback cycle is so long, that once a bug is discovered, Oh, you know, maybe they didn't even write the bug somebody else did. Now they're going to go find the cause and fix it and not break anything else in the process. So you have to cause process to repeat that find time is a huge waste. What if we could do something different? As your Dijkstra suggests that we should not waste your time debugging, we should not put the bugs in the first, we should not introduce the bugs to start with. Now Dr. Dijkstra didn't tell us how to do that, though. So we've got to go what what could we do and kind of like integral calculus and and calculating the area under the curve. I think test driven development is kind of an approximation of proving what software is doing. It shows you what it's doing. Doesn't show you what it's not doing, I suppose. But it's kind of like that. And so back to this marriage. Extreme programming, you all know about scrum. Okay, what about extreme programming? What's it built on? Well, you as an engineer, it's very appealing to me as an engineer, because it's very once you kind of have experienced it, you know, it's solid problem solving. And you're cranking the knobs up to 11. And you know, if, if quality is important, we're going to deal with it every day. If testing is good, we deal with it all the time. If reviews are good, we're reviewing all the time. If it's good to talk to the customer, you know, talk to the customer every day. Now scrum has this on their list. And if planning is important, you know, let's keep the plan alive. Now scrum does this too, if you're doing scrum as it's supposed to be done. So here are these practices. I'm not going to, of course, talk about them all right now. But they are the engineering practices that make it possible for you to survive iterative development, not just survive, but to succeed and thrive in iterative development. At the core is this micro cycle. It sounds so simple, so ridiculous. But it works so nicely. Write a test, watch it fail, make it pass, clean up your code. Any test driven developers in the crowd out there? I'm seeing some hands. Good. Good. So get some more. Okay, so we want what if we had to spend our time at the bottom of the waterfall before test driven development, what happens to us after test driven development? Life is more like a fast moving stream, not without bumps, not without turbulence. But you get something to work in pretty much stays working for its useful life until you change your mind about how you want it to work. If you change something, it starts working differently than you defined how you want it, you get notified, right? The code tells you it's broken. It changes the physics of development. We make a mistake still. This is human nature. And actually test driven development before I started doing test driven development. I thought I was good at programming. And I realized, oh no, you actually really are bad at this. Because I make mistakes. And little mistakes all the time. Per minute, probably measurable per minute. If I'm typing, definitely if I'm typing. And then that means my fine time is the work I just did. So because I have a fast feedback cycle, I can check it, I can run my code and see that the fine time is low. And now I don't have to go chase around and find those bugs that I'm going to have a hard time trying to find. Right. And the fix is usually easy. Sometimes one test, a new test passes and 15 other existing tests fail. You just saved yourself from 15 bugs potentially. And then that's when you start to think, hmm, there's something here because I forgot about that detail that all those things depended on that thing I just changed. Oh yes. So it's not all the test followed by all the development. It is a feedback cycle. This is what makes it successful. People like feedback cycles too. Right. You get rewarded for your work here. Now, you know, you might think, though, you've got 10 years experience. Why should you learn this thing? Because you're already an experience. You got a senior engineer position. Why should you learn this? And what I've kind of discovered of many people, they're 10 years is kind of the same year over and over again. I know my first 20 years, I did see a lot of different technology, but my technique was certainly the same year over and over and over again. Unfortunately, that I'm an expert beginner. You passed the aptitude test. Okay. Now, do you do TDD? This is kind of a rhetorical question. I saw a bunch of hands go up. You know, do you create unit tests? You know, writing tests after is almost as good as test driven. I don't find it as as good because of the influence on design, but it's almost as good. But unit tests are really critical. I'm just checking my clock here. I got about five minutes left. I think we're pretty good here. So here's the testing pyramid that I like to use as a metaphor. It's not my invention. I think first place I saw it was my cones. And unit tests at the bottom provide you a solid foundation of software that does what the programmer thinks it's supposed to do. Now, that's different than working code. You don't know if it works. You just know it's doing what the programmer thinks it's supposed to do. All right? So the middle of the pyramid is about tying those things together and getting them to collaborate and produce behaviors, features, right? And the top of the pyramid is interacting with the system through the way that the users can interact with it. Now, unit tests tell you the code does what the programmer thinks. The tests in the middle tell you the code does what the customer wants. Hmm. Why don't we just do considering we don't have much time? Why don't we just do the tests in the middle of the pyramid and not do those ones about the programmer? Well, let's go see if that's a good idea. Imagine a simple system with three components, each with 10 states or 10 complexity 10, and you decided to test them together as a subsystem. How many test cases do you need? Now, if you can make a thousand thumbs up, go up right now. That's the right number. 10 times 10 times 10, a thousand tests. Forget it. It's not worth it. But if you're doing unit tests and you wanted to thoroughly test each piece, how many unit tests are needed? And now what we have are 30 tests, 30 tests. Now, that's and we need some integration tests, but you got to go to Nyash's, sorry for not pronouncing your name right, Nyash's session, his talk today, I want to do about the integration. Okay, I'm talking about the unit, so he's going to solve that other problem. Alright, so this is that. Now you do need to make sure everything hooks together properly. And here's an example of this code compiles and links, but I think there's a couple use cases that aren't covered in the tests. Pretty sure about that. Now manual test is prevalent in our industry. And as a motivation to start to automate, let's just look at, you know, how companies are typically structured and kind of what that means. So here is a typical organization working in iterations. And you have so many development engineers and so many test engineers. Implicit in that is that the effort to develop something, we say that again, implicit to this relationship here is that the effort to develop something is proportional to the effort to test it. Because you could count how many developers there are and count how many testers there are, there's an implicit assumption there. Now, the system's Bible suggests that if a system is working, leave it alone, don't change anything. And guess what that means to all of us? We don't have a job anymore. Okay, so we're gonna ignore that. Okay, thanks, John. Do you have anything else for us? And John's got a lot more for us. He goes, Well, realize that systems don't appreciate being fiddled and diddled with. I don't know if those terms translate very well because you learned probably better English than I did. Fiddled, you know, well, messing around with changing the system is what it has to deal with. Kind of a funny way of saying it. Okay, and the subtitle of John's book is the study of system antics, which looks like a very serious academic word, but actually is pretty funny. It stands for system antics. Systems act up. Alright, systems act up a system, right, something that is there for a goal and antics frivolous eccentric activity. Alright, let's just look at an example. And here's an example. A family system. And of course, you've tried to tame the system and take a family photo. And of course, the photo is in failure mode. The crowd is in failure mode every time. I don't have serious pictures of any of these people, I don't think. But because systems act up, we have to be careful. So what does that mean? We have to be careful. That means after the second iteration, we must retest the first iteration. After the third iteration, we must retest the first two after the fourth iteration, etc, etc. What does that mean? We've got this unsustainable growth of effort that's needed, and we don't have the effort to put into it. So we're accumulating risk. And then one day lightning strikes at the wrong time. And guess what happens? Boom, there's those flames again. Alright, what we want to do with test driven development and test automation is start to flatten the curve. I'll flatten the curve. Ha, how timely. I haven't had my own little large sized coronavirus here for the occasion. But alright, so it looks like I'm out of time. And this is probably a pretty good time to stop. I do it. Sometimes if I talk slower, well, or faster, I might have gone further. What I'm hoping your takeaway here is, oh, yeah, quality code matters. The lawyers are coming. Alright, there's blood in the water. And as development people, if we don't want to be led around by our nose, we better get our act in order. Alright, I know you're different because you do embedded systems or whatever the thing that makes you different. You think that this isn't for you because you're special. Yeah, you are special. It just doesn't matter. This stuff will help you. Alright, so repeat after me again. I'm a programmer and I write bugs. And I invite you to stay in touch with me. And to don't think about the shortcuts. Think about the habits. Kent Beck told me something 20 years ago. He goes, I'm not that good of a developer, but I've developed good habits. And this is I think kind of a key idea and excellence is about developing good habits. Here's a little bit about how to stay in touch with me. And I understand we're going to go off to the lounge and chat. Thank you very much. Thanks for all the thumbs up. That was really a nice way to get feedback and have a good rest of your day. Alright, thanks a lot, James, for reiterating the importance of technical excellence. And I mean, I loved all your jokes. Really timely, awesome. Let's see if we have questions for you here from the audience. Okay. So I see a question by Jeevan. Jeevan is asking, convincing developers and management in taking up TDD is a separate way and challenging from your experience. What are the best ways to convince them to achieve this apart from numbers? So other than showing numbers, what are the other techniques you've used to convince people and management to embrace TDD? So one of the things that's kind of lost from the beginning of Agile, extreme programming and Agile 20 years ago, is why are we doing any of this stuff? And the reason we're doing any of this stuff is because there are serious problems we want to solve. So if your problem that you want to solve is delivering defects to your customer, are you willing to actually change how you work for that? If those defects are causing you to be late, are you willing to change how you work to try to do that? Okay. Well, I'll at least listen to you about what this TDD thing is how it's supposed to do. It's a pretty short logic chain. I gave you several of the argument, several of the models here, like debug later programming versus test driven development. That's one model. I've got a blog article about that. And then the sustainable manual test is unsustainable, the flames at the end. Right. Why do we have to automate because you can't retest everything manually? And so these are a couple of motivating things. If you don't experience those problems, you're not going to want to do it. But if you are experiencing those problems, the logic chain, you do the logic chain, and then you have to get people to do it and to try it. Okay. In my training class, I start off by saying, hmm, do you people like writing bugs? Do you write bugs? Yes, they all agree they write bugs. Would you like to write less of them? Sure. Yeah, that's a good idea. Here's how we're going to do it. And they go, really, that's going to work. And I have them do it. And they go, that's never going to work. And I have them do it for two more days. And then they're starting to think, huh, I think that's going to work. So I don't that's my method. But it takes a lot of time. It's a skill to grow. So thank you for that question. Right. We have one more question here. And I'd encourage you to please put it in the Q&A section. There is a question from Radhika in a DevOps situation or scene. Do you suggest to separate the testers and the developers? A friend of mine keeps attributing this statement to me that I might have made at a conference once as a underhanded remark. And the statement was talk to each other people. Okay, so I'm quoting Marcelo, who quotes me saying that I said, talk to each other. So, you know, are there different skill sets there? Are there different focuses? Should they be separate? What does that mean? Should they work together? I think it's pretty clear they should work together. The handoffs are very expensive. So working together would be, I think, very important. Now, different skills. You know, so, you know, there's probably a lot of different ways to answer that question. Some people criticize the idea of test driven development because it's a developer writing their own tests. That's different than the tests at the middle of Pyramid, where you're going to involve more of the company, right? So I kind of like to ask, whose responsibility is it to make sure my code does what I think it's supposed to do? Me? Whose responsibility is it the product works? Right? That's all of us. Right? So you better talk to each other. You're going to be successful with that. All right, great. I think those were the two questions that pretty much came up. If you don't mind, James, I'll throw in one quick question from my site. So it's been a few years now that I've been making the statement that code is liability. It's not an asset. The value of code does not increase over a period of time. And the little code you have, the better off you are. I would love to hear what's your take on that. I've got some big code in my website. I'd like to be smaller. Some of the places where before I knew how to test drive in a Ruby on Rails environment, if any of you know how to test drive in a Ruby on Rails environment, I'm actually looking for help for integration testing. That sounds... Well, I know code does something. So it's useful. It does something useful. I know code becomes a drag because we built too much of it and we don't understand it. So I can understand that liability. I know right now I'm a little bit afraid when I start deploying the self-paced training that I'm working on that my IT systems might break. So I think it's an interesting insight. Of course, any good life involves a balance of assets and debt, right? So maybe not. Maybe you don't have to have any, but assets and liabilities. So every business has both. So I'm going to have to try to square that circle because we need software, obviously, and it provides great value, but then the wrong software can also hurt. So I probably need to understand your premise a little bit more too.