Embedded - 109: Resurrection of Extreme Programming

Episode Date: July 15, 2015

James Grenning (@jwgrenning) returns to discuss TDD, Agile, and web courses.  James was on Embedded.fm episode 30: Eventually Lighting Strikes. James' new company is Wingman Software. His excellent book is TDD for Embedded C.  James suggested Training From the Back of the Room! as resource to people looking to put together a class. He uses and recommends CyberDojo as a coding instruction tool. Before Agile was Agile-for-business, it was Extreme Programming. James recommends Extreme Programming Explained. James will be the keynote speaker at AgileDC in October.

Welcome to Embedded FM, the show for people who love building gadgets. I'm Alicia White. My co-host is Christopher White. This week, James Grenning is back. James is the author of Test-Driven Development for Embedded C. And we're going to talk about many things, including how to teach classes online and in person and probably some test-driven development too. Hi James, thanks for joining us again. Chris, nice to see you again. Thanks for having me back. Nice to be back Alicia. You were on episode number 30 about 18 months ago. We talked about getting started with test-driven development. So what's new with you? Well let's see in that since that time I've started doing business under a different name, Wingman Software.

RenaissanceSoftware.net still exists, but Wingman-SW.com is where I'm putting my energy now. I've kind of tailored my website more to help me with the delivery of my training. And that's been occupying my time recently. But you're doing different sorts of training too, right? Well, most of my training is involved with helping engineers learn the technical practices of extreme programming, and that's specifically embedded software engineers. And so my training has taken a bit of a turn. Most of my work has been on-site with clients, usually for a whole week.

And what I've been doing is providing some offerings that are shorter, maybe easier for people to get started in, and also some web-based training where it's live. I'm at wherever I happen to be in my office and working with people over a WebEx kind of meeting forum and helping them learn test-driven development that way. Extreme programming. I haven't heard that term in a while. Could you explain it? Well, extreme programming. Back in 1999 or 1998, Kent Beck, along with some other people, defined extreme programming. Kent Beck wrote a book called Extreme Programming Explained.

And extreme programming was the precursor to agile, one of the precursors to agile development. In 1999, I saw Kent Beck demonstrating this thing called test-first programming at the time, which has now morphed into test-driven development. It's one of the practices of extreme programming. So in extreme programming, there's 12 different practices. One is test-first development, now called test-driven development. Some of the other practices are around managing an iterative cycle. Sort of agile stuff.

Agile stuff. So some of your listeners probably are practicing Scrum, but likely most Scrum practitioners are practicing just the easy part, the management cycle. The meetings, the endless meetings, the constant and endless meetings. Well, they're short meetings. But there are so many of them. Well, there's one a of them well there's there's one a day and then there would be one every two weeks yeah okay yes there are yeah okay we you know we might be off topic already which is okay with me but uh so the uh those practices uh

engineers tend to look at them like micromanagement and I'm kind of feeling that from Chris right now the way he's looking at me and so it's being implemented wrong extreme scrum was invented by people trying to manage development extreme programming was invented by people that want life to be safe for programmers, so that was one of Kent Beck's goals. And so he and Ward Cunningham, a name that people might be familiar with or should be familiar with, he's the inventor of the wiki, so he impacts our lives every day.

These two bright guys define these practices that really help get software done and allow you to change your mind about what you want the software to do and to be able to change your mind about what you want the software to do and to be able to change the software without fear and improve the software for a long, useful life. How much of your guys' code out there in radio land has gotten so you can't maintain it anymore? They've invented a set of practices that help us engineers create code that has high quality.

We can deliver it quickly and we can change it. Cool. Does it include pair programming as part of the core or is that? Yeah, pair programming is one of the practices. Now that's one that scares most engineers the most. That's funny. The times that I've had really good pairs, it's been wonderful. The times where the pairs aren't matched well, either temperamentally or skills-wise, those were the times when it was just like,

why don't you go take a break and I'll just finish this? And that's totally not the right way. It's like any other partnership. You can't just find two random people and hope they're going to work well together. Yeah, and there's also a kind of a way of working and there's some learned things that have to happen there. It's not like a marriage where you commit to one person for the rest of your life.

It's more of an opportunity to get help and learn from someone. So along with this, there has to be a desire to collaborate and a desire to learn from other people. Now, if you think you already know everything, you're not going to do too well, okay? Because you don't actually know everything. And... Well, then if you're afraid of letting people know that you don't know everything, there's that intrinsic engineering fear that people are going to find out that you don't know anything and then they'll make fun of you. Right. And that was one of my initial fears. It's like, you know, pair programming, Fear that people are going to find out that you don't know anything and then they'll make fun of you. Right, and that was one of my initial fears.

It's like, you know, pair programming. I've got to show these people what I know and what I don't know. There's no hiding. Okay? But that's good because everybody is like that. Everybody shares a certain amount of fear of showing what they know and what they don't know. And then if you can be comfortable with what you know and you don't know, and you realize that everybody has those different things that they know, you have an opportunity then to learn.

The humility that you go to a pair programming session with should help you be able to learn something from whoever your partner is. And I usually find myself as the senior person of the pair, but I always learn so much from the people I'm working with. It's kind of surprising. I mean, it surprised me, and now it doesn't surprise me anymore. I just expect it. We were asked recently, how do you learn new things? And I think pair programming is one of the ways

that you can really hands-on learn new things because the other person knows things you don't. Although I do find it hard to find a good pair. Partially because I'm a consultant, and so we don't always integrate into the teams fully. But also because I had that one really awesome pair, and that's what I want now. It's like finding love and then

you know after that you don't get it anymore it's no good so but test driven development is your core for for the two classes you teach and for the book you wrote yes uh what is the best way to get started i mean other than listen to the podcast that we recorded. Oh, yeah, you have to listen to that, and you have to attend one of my training classes. But I'll tell you the really short answer in three words. I was going to say try it, so you've got an extra word in there. Write a test. Oh, okay, write a test, exactly.

Write a test, that's how you start. I did a presentation to the South Florida Agile Association, and they had a bunch of people in a room, and I sat down on a chair and said, I've just got one slide. Here's what you do. Write a test. It was kind of silent like that. I said, no, just kidding. And then I had like a whole bunch of slides to back it up. But you get started by writing a test. Okay, maybe that's not good enough. So I could answer this question. I've got maybe five points, I would say. And let's see if I can remember them.

The first one would be, what problem do you want to solve? As a developer, are you satisfied with the results you get? Do you mind having to chase defects? Do you like to have code that you're afraid to change because you don't know what's going to happen when you change it? That's a very loaded question. You seem a little loaded, but okay. What problem is it designed to solve?

Test-driven development? I already know how to program. Why should I change? This is generally the attitude of many of the people that I find myself in front of. So I first need to kind of rope them in and find out, are they interested in solving this problem? Now, if they don't think they have a problem, then, you know, I could leave early and send the invoice in. No, actually, I would just leave early. But they do usually understand they've got a problem. And so you have to accept that there's a problem that you'd like to do something different, because test driven development

is quite different. So that's the first step is to accept that, you know, I am a programmer and I write bugs. Right? Anybody who can say the first and not the last is either lying to themselves or some sort of freak of nature. Yeah. So I don't know what the other four points are, but if you can, a good way to start is to, programmers have to accept that they're going to write bugs, but not be satisfied with that. And so I'm a programmer.

I write bugs. The world says when people write programs, they create bugs. And so what we have to do is go find the bugs. I would like to prevent defects. And so I'm interested in appealing to people and having them envision what if instead of writing bugs, they discovered most of their mistakes right away. Not all of them, of course, but they could discover most of their mistakes right away and not write so many bugs. It seems like a good idea. Yeah.

Is there one true path, one correct way to do test driven development? One true path, one true correct way. Well, there is a sequence of steps in C and C++ that you would follow. And that sequence of steps is write a test. You write a test for code that doesn't exist, possibly. It won't build, and you go through each steps of your compilation, getting the header file to match your test file, then getting your implementation to match the header file and the test, watching the test fail, because you want to make sure that that test is correct.

And you intentionally make wrong code first to make sure that the test case is correct, and you intentionally make wrong code first to make sure that the test case is correct. And then once you're sure that the test can detect the wrong answer, then you add a little bit of code to make it so that the test case passes. Now, your code isn't complete yet, but that test case works. You've cataloged one behavior of the code. And you've started to evolve the implementation. And you're going to evolve your implementation one behavior at a time. And one behavior at a time,

the way you teach it, it really is one line of code at a time. One simple line of code. And this is the whole cycle for every line of code. That's right. Well, let me ask you, how long does it take to find the cause of a bug? Well, it really depends on the bug. Those semicolon bugs are just impossible. That's not a bug. That's a syntax error.

Depends on where you screw up the semicolon. So, how long does it take to find one? It can take days. five minutes to three weeks just to narrow it down for you or maybe there's bugs in some people's bugs lists that they can't find that's never happened to me i don't i okay that i have met people who say that and that's usually when they start paying me the big bucks i've never left a company glad that i never have to think about a bug again that would be nice okay i'm also lying okay all right i thought you're being serious here for a second i can look into your eye and you do have a big smile on your face so so i asked that question kind of rhetorically and uh i asked it a second time

because i was trying to get from you i don't't know. The answer is I don't know how long it takes because you can't know how long it's going to take. So people don't mind doing small steps when they're debugging. But they do mind doing small steps proactively to prevent bugs. I don't get that, although I do understand that test-driven development is really foreign. And so I can understand that pain of not knowing how to do something. But accepting, people do accept small steps once they're debugging, because they walk through each line of code one step at a time. If you were proactive going one step at a time, you could prevent bugs in a predictable way.

Predictability might be more valuable than the speed that you might get by rushing your work and leaving behind a trail of bugs. Yes, the time spent debugging transformed into test-driven development would give us better software. I think so. The interesting thing, too, is you didn't say in your points this produces software faster. You don't ship faster necessarily. But when you're scheduling a project, you tend not to include the time for debugging and stabilization. You list out, well, how long is it going to take you to write this code, Engineer A? How long is it going to take you to write this code?

And you lay out your Gantt chart and everybody's probably equally unhappy. But usually there isn't a... Because they know it's all lies. There isn't an amorphous debugging period, because like you say, we don't know how long that's going to take. We don't know what bugs you're going to find, and perhaps it's three quarters of the project timeline. Perhaps it's five times the project timeline.

And so it's hard to justify. It should be easy, actually, to justify to management, look, this makes things more predictable. This makes it so that we can have some sense of the quality of the code as we go along. But it doesn't seem to be that way in practice. It seems like, oh, you're putting a bunch of stuff in front of getting the features out and getting demonstrable working code

in front of the non-technical people who are interested in seeing it. Then what engineer is going to stay staunch in the face of, you're going to do it right this time and not have so many bugs, aren't you? You know, have your manager telling you that. That would be really nice to hear from a manager instead of... No, I'm saying, you know, we can't meet the deadline. You put all this time in the schedule for debugging.

Why are you going to create all those bugs? I'm being a debug later... I call what isn't test-driven development, I call it debug later programming. So if you don't change how you work, why would you get different results? So if you're going to continue to do debug later programming, why would you expect this project to be any different than the previous project? You shouldn't.

But people will be pressured into cutting out that debug time, which we don't know how much we need anyway. We end up calling it different things, system integration and all this other stuff. But we all know what it means is debug. It's like, oh, yeah, can't we get that integration done sooner? But, you know, by the way, I take it, Chris, as a complete insult that you're telling me. I've got a smile on my face now. They're smiling at each other, yeah.

Okay. James, why do you like being a slow developer? Okay. Why do you like to be a slow developer? And actually, I continue to do test-driven development and have since 1999. This is 15 years. For you people that are listening to this way out in the future, don't you have something better to do?

But anyway, I continue to do it because i can work better i get my work done quicker i have a higher quality and i can make a change deploy my change with confidence and so my life is better so i i would to engage with this drama i would love to be a slow developer, but I feel like I'm not allowed to be a slow developer in many circumstances. And I do feel like the quality of my code suffers because I'm trying to hit the sprint deadline. And it drives me nuts.

It feels to me like Agile is in conflict with this. But maybe it's just the way Agile is being done in my situation. Yeah, so the idea is sustainable pace. So if you're capable of delivering so much, there shouldn't be pressure for you to deliver more

because high quality is part of going fast. If you don't keep the quality of the code high, you're going to be chasing around problems. Now, Chris, of course, you're an expert developer and don't have those kind of problems, but there are people that do. Thank you. Thank you for that. The way to go fast is to go well. If you want to drive your cool car fast, you've got to drive it in control and not do anything too crazy dangerous.

No, that's very true. If you go to race car driving school, which we did and it was fun, they tell you you cannot go fast all the time. If you want to get fast around the track, there are times when you have to slow down and that makes you faster. Why do cars have brakes? I have no idea. I've never used them. Sorry. Cars have brakes to go fast.

If you didn't want to go fast, you wouldn't need brakes. That's true. Yes. Right? Essentially, brakes are an invention so you can go fast. Okay? So you've got to know when to slow down and maybe take being the careful route of tdd slows you down while you're creating to prevent problems later so i know a lot of people that are very

experienced i learned this when i was i discovered tdd when i was uh 20 years of experience as a professional and it changed my life the last 15 years. Yeah, of course, James, because you teach stuff. But it also changed my life as I also maintain my own website. And TDD plays an integral part in that. I'm in a hurry sometimes. And do I break the rules sometimes? Yes, I do sometimes.

But generally, if I'm adding anything of any... That word was rattling around my head, and it's not really complexity. Actually, if anything has an if statement in it, I better write a test for it. Yeah. Conditionality? I get if statements wrong as often as I get them right. So if I find myself doing conditional logic, I need to write tests. Kind of a funny story.

In the early days of, well, early days, I just redid my website in Ruby on Rails. And I don't know Ruby. And I don't know Rails. I had a friend of mine get the website started. And then he was going to help me learn it through us pairing. But then he got a long-term gig and I didn't get to talk to him for six months. And so I had to figure it all out myself. I have a script to deploy my website.

Anything I find boring, I've got to write a script for, because writing a script is fun. Automating a boring, repetitive process is fun, and doing a boring, repetitive process is not fun. Automating a boring repetitive process is fun and doing a boring repetitive process is not fun. And, you know, I want to have fun. And I find that if I'm doing boring repetitive processes that my quality suffers and then my clients see something that doesn't work and I'm in there talking to them about quality and they say, well, James, what about your quality, your qualities? So I can't do that. I've got to live what I'm teaching. So my deployment script for my website had an if statement which said, if the directory is named such and such, deploy to it. Well, guess what?

The if statement was wrong and the directory was wrong. So my website deployed totally by accident for about a year. And then I did a fresh build. I created a new cloud server and did everything with all the automation that was there. It put the website into the directory named the wrong thing, and it failed when I tried to deploy the next step because the directory was wrong. And I found out that that if statement was wrong. I went and fixed it.

Then my website deployed. I got to chase that same bug. No one's ever done this before about wrong named directory. I got to change about wrong named anything. I got to change it several more times over the next two weeks. So code working by accident is not that great of a thing my favorite thing to say in in great consternation is why does this work yeah and those are the ones that confuse me the most because you look at the code it's like this is broken yeah and it's fine how did this ever work yeah yeah

some people in my class today were uh had their passing, and they were very proud of it. And I looked at their code, and it's like, it's passing for the wrong reason. And I said, you know, this code is broken. You can't do that. And they said, oh, no, it's fine. And I wrote another test which showed that it was broken. And they're like, what's going on? It's like, well, you overwrote this other thing you weren't supposed to overwrite.

Their code is working by accident. I want to know when my code is working by accident. I want to know when my code is working on purpose. I want my code to work on purpose, not by accident. And that is a very lofty goal. Well, and that points to understanding what your code is doing. And I would say it's hard to understand what your code is doing if you don't have a test for it. All right. So I actually didn't trick you here to talk about test-driven development because you spent the whole day talking about that,

and I wanted to ask some other questions. Okay. I've talked to some listeners and some friends who are teaching classes, who are just about to start teaching classes. And some of them are in-person classes, multi-day, and some are online. When I give conference talks that are an hour long, it takes me 10 hours to prepare for it, at least.

And so when I look at these people talking about doing 24 hours of lecture, I'm like, okay, so for the next six weeks, you're just going to be prepping? How do you prep for a class? How do you put it together? How do you define what you're going to do? And how do you make sure you put breaks in the right spot? Well, let's see.

The training class I taught today, I prepped for for about 15 years. Yes. That's not the answer she was looking for. Not what I was looking for. That's the answer you're getting right as the first answer. Okay. But I think, you know, I looked at, you know, so what you're saying is 10 hours to prep for a one-hour talk? That's probably about right.

A day for an hour, maybe more. Yeah, definitely more, depending on how willing I am to read my notes. Yeah. And then, you know, I think you've told me before that you usually give a talk only one time. You should give it more than once, because you can make it better. But maybe you're bored with it. So repetitive, boring things. So then you shouldn't do it.

No, it's more that I give them at conferences, and it didn't seem like most conferences seem to want original talks. And then I'll re-give them at brown bags, or if I can convince somebody to sit down and listen to me for no reason. And they become blog posts, so it's not like the content doesn't continue. Right. But, yeah, I don't usually give the same talk more than once. And now that things are videoed, there seems even less reason to do that for me.

Yeah. But they're just hour-long conference talks. They aren't. Sure. Classes that are interactive. You work with your students on their code sometimes, often. Right. We'll be doing that tomorrow.

So do you have any advice for people who want to do a class? Yeah, there's something that's changed the way I do training pretty much. It's called learning from the back of the room. And I was on, somebody recommended it to me, a trainer in the, probably in the agile space. I forget who that was was but that person had suggested I look at this book and training from the back of the room involves asking people questions and making sure you get an answer from everyone now if that's done verbally at least one of the aspects of training from the back of the room that I found to be really helpful is using post-it notes. So what I used

to do would be after an exercise is ask for impressions of the exercise. What did you learn? Someone would give me the right answer. I would make an assumption that everybody actually had thought the same thing. And, you know, later when I read the reviews afterwards, I didn't really get that. You know, I don't know why they didn't tell me. Nobody wants to be the one who's considered dumb. That's right. It's easy to be the teacher's pet because then everybody thinks you're smart. But the second person who didn't quite get it as well as the first person, and the other 29 people in the class,

they don't want to admit that they're not as smart. They didn't quite get it, yeah. So what I do is to make it more anonymous is I started using Post-it notes and have everybody answer the Post-it note and answer three questions. What did you like about test-driven development? They usually all like something, but they all are harboring concerns about it because they think it's slow like Chris.

And they think that they'll have to get permission. And there's a lot of things that they're worried about. They might not think of all the tests. They might not know what tests to write. There's a lot of things they're concerned about. Or they wouldn't be able to get right next to the hardware with it. They couldn't write a device driver. There's a lot of fear after the first view of it.

So I try to get their concerns. So there's one Post-it note on what do you like, one Post-it note on what are your concerns, and then another one is was there anything that surprised you. And I first collected those on Post-it notes, and I used to take photos of them. But now I'm starting to use a virtual Post-it note board, and I'm going to start to screen scrape those and put them on my website because they're pretty fascinating what people like about test-driven development and when they first see it.

And then the concerns that they have are usually common. There's maybe five themes of things that they're concerned about. And then what I make sure is everybody hears what people liked, because it's like, hey, it's cool to like this, because everybody liked different things. And hey, I like that too. So that kind of nice thing kind of bolsters their confidence. But then everyone's concern gets to be addressed. Now, it means this takes some time. So I might not cover as much material, but covering the material is not as important as making sure that people get the stuff we already talked about. So they need the foundations and things. So this training from the back of the room, you know, I learned this

technique for getting people engaged in the material and making sure that I know where they are. Okay. So it's, it's about, you know, getting them engaged in, in discussing and such. So there's that. So training needs to be experiential. If I were to do a three-day training class with me talking and them listening to me, I would be dead at the end, and they would have slept for two and a half days. How do you balance it, though? Well, you talk for a little while, and then you do some kind of an exercise. So, for instance, today, yesterday, I talked for about an hour in the beginning to get people to understand why they would want to do test-driven development.

And actually, before the training class, I have them do a survey. They tell me what they like. I ask them, what do you like about development? What don't you like about development? What don't you like about development? And why did you come to this training? They go to my website and answer those questions as well as some other questions. And by the way, they're all live on my website. So you can, you could go look at them and see what, uh, the kind of people that are taking my training. Uh, what I'm looking for is, are these really engineers that are in my class?

Do they like problem solving? Do they like creating things for their customers? Are they motivated by the things that us engineers are motivated by? Okay, so that's the first thing. Are they concerned? Do they not like the things that they shouldn't like, like chasing bugs? Actually, some people like chasing bugs. It makes you feel heroic.

Well, yeah. And then that same person will likely answer, I hate bugs. Okay, so they like to chase them. The chase is fun. The actual bug is just annoying. Well, they should be in QA. Yeah. Well, you've got to find the bugs.

You have to be an engineer for that usually, but maybe not. It depends on the skills of your QA people. And then, you know, so what do you like and what don't you like so much? So when I discover the things that they don't like, you know, chasing bugs, big documents, bureaucracy, rushed deadlines, scrum meetings that waste their time. Micromanagement. Somebody else's bad code. They don't mind their own bad code. Who wrote the bad code in the first place? Usually not the people in my room.

I always give them an absolution on that one. So I try to find out something about them that way so I can relate to them. So how do I generalize this for somebody else? I don't know. But for test-driven development, I want a motivation behind the thing I'm going to teach them. So I told you earlier about we want to prevent defects. That's one grab.

And the other is, what if you could do more of what you like? You like problem solving? You like creating something? What if you could do more of that and less of the stuff you don't like? Two hooks, right? So I think it's important to have those hooks early in a training. And I'm no, I mean, I happen to be a professional trainer because that's what I do because someone pays me to do it. I wasn't trained to be one. I'm just a guy that likes this stuff and finds it fascinating to help other people learn how to do it. Okay, so get people engaged.

Know why it's important to learn what they're learning. These are important things. of really handy, of being able to get from everybody their reaction and their thoughts and feelings and concerns. And that does seem to carry over with web classes, which is what you have been doing more of recently. Yeah, I started doing that back in January. I had a number of clients that were almost closing. I was almost closed on their business, but it didn't close.

And a couple of them asked me, is there an easier way for us to get started that doesn't involve a whole week of everybody away from work and doesn't involve you having to come here? Is there any other thing we could do? And I used this program, this website called Cyber Dojo. Yeah, that's what you use. I remember when I took your class, that was where we typed in our answers.

Yeah, well, basically it's a Linux box up in the cloud, and it's the simplest development environment ever. It's an editor that everyone knows how to use right away. And you push the test button and it commits your changes, runs your build, and tells you what the code is doing. One thing about that is it's in the cloud. I can monitor every line of code change that people make no matter where I am in the world. So I had this bright idea that I could facilitate a training class from wherever I happened to be. And I could advertise it online. I started tweeting about it and I called up one of my clients who was on the fence and they said, yeah, we'd like

to send some people. And the first one I did, I had 16 people. It was kind of, I guess I didn't know how to say no. So I had a lot of people sign up for it, and I didn't really know how to do it, but it turned out all right. But it's very odd to be trying to teach someone and not be able to look in their eyes. Like if we were trying to do this podcast and I'm not in the same room with you, that would be harder than we're doing it in the same room because we can see if someone's getting it. So that's a challenge. It makes it not as much fun. But I'm finding that people get a lot out of it anyway.

At the end when they review it, they say, gosh, it would have been better if you were in the same room as us, but it worked. And so I have one client that's had me do it for them privately like six times. And you are teaching web classes. You aren't just recording the information and lecturing. No. And there are people who do that, and there is some goodness with that. Yeah.

I probably will do that too. I'm looking at some options for doing that because I'd like to have another way for people to get started without me having to be on the phone or fly somewhere. And it could be an interesting business to be able to have where people could get started with that. And then when they get to get deeper, then I could get involved with them more. Or maybe not. Maybe there's some people it's enough to get started is just give me enough of a nudge. So I get the idea and I'm, I'm good to go. So, um, I'm looking at some options for that. I know that, uh, Mark Vandervoort, who you had a few weeks ago or a few podcasts ago, uh, was doing that. Uh, those guys do that. I would expect that to be,

you know, well, very well done. Cause those guys know that. I would expect that to be very well done because those guys know what they're doing. They're early adopters, pioneers in this stuff. Well, sir, and people learn differently. Some people need more direct contact. Some people need more interpersonal back and forth. And some people just want to be able to push the 1.5x on the lecture speed. Right.

You were admitting to that, weren't you, about you play your podcast back and fast forward or something? I do. And now I've realized that my phone won't play videos back fast, but my computer will. So now I'm watching all my YouTube stuff on the computer. All right. Yeah, it's really not a good habit to get into. You're still talking nice and slow, though. Except for those people who have a speed app.

So there is some technology to host the classes. Yes. What do you have? I use, well, CyberDojo, like I mentioned, So there is some technology to host the classes. Yes. What do you have? I use, well, CyberDojo, like I mentioned, is a system built by a guy named John Jagger. He lives in the UK. He's created a very wonderful environment, open source, for people practicing programming, where what you'd like to do is get together and practice programming and not have to set up tools for two hours and use all your time doing that.

So the tools are set up. That's a good point, actually, for doing classes. Yeah. Don't spend the first two hours setting up tools. It's just no fun at all. Yeah. And it's worse for the person who actually does it ahead of time like you asked them to. Yeah. Sorry. You know, my life has been simplified

and my stress has been greatly reduced by John Jagger having created CyberDojo and being happy that I'm using it to deliver classes because now I can start teaching test-driven development within minutes of getting into the room, even though I talk for an hour anyway. I could start right away having them do exercises. In the past, I used to send out zip files with instructions and threats and, you know, get promises from people that, yes, everyone will

do this and show up. And the one guy that was too busy, his system isn't set, and then it makes me look bad because he didn't do his work, and everybody dings me in the evaluation. Okay, not that evaluations for my stuff go live immediately on the website. People can say whatever they want. I don't do it for the evaluations, but I use evaluations to get better, and I don't want to waste 16 people's time because one guy didn't do their work. So having the technology of all the tools are there in the cloud

means we can get to work right away and I don't have to wait. In some of my week-long environments, we work in their code, but we have several days now to get their tools set up. I can tell them on Monday what to do, and then by Thursday they're ready. So CyberDojo is something I use for all my training, and it enabled me to be able to do this delivery from anywhere in the time zones that I'm near kind of training. I don't want to use it to talk to people that don't really speak English directly. I need to be with them and in time zones that are too far from my own because I don't really want to get up at three in the morning or stay up until three at night, you know,

three in the morning either way. I don't want to do that. So that technology has really helped. The other thing I use is Webex. Now I use use WebEx because I happen to have a WebEx account. Cisco is one of my really good clients, so I like telling them that I use WebEx. Citrix, if you guys wanted to call me, maybe I would start using Citrix. So you're not attached to that? I'm not attached, but I do have my website set up to work with WebEx nicely. Is it much cheaper for people to have a web-based class? Do you only do it privately or do you have public ones?

I do it public and I can do it private. I'd prefer to do private classes in person. Because then you can look at their code. Or work with them on their... Yeah, I can look at all their exercise code, every change that they make with Cyber Dojo. And I limit it to a two-day training class when I'm doing that because it's exhausting to deliver a class that way because I have to be on my toes the whole time, right? Either speaking or watching them program, clicking on everybody's progress so I can intervene. If I'm in a room with someone, I can look around and see, is anybody in trouble?

If I'm remote, I've got to focus on that. It's quite tiring. So I do a two-day version, sometimes spread over three five-hour days. Which has lots of benefits that you can't get if you're in person, because in person you really do have to pack it all in, because traveling is hard. Yeah, but it's more fun to be in person, but then I pay by having to travel. Okay, so there's trade-offs. So when I do too many of the remote ones, then I think I need to get on the road. And if I do too many road ones, I need to think of how I get off the road. So it's a trade-off.

It's a balance, yeah. It's a trade-off. But if I was doing the same thing I was doing a year ago, it would be, again, repetitive and boring, but I keep changing how things work. And I mentioned my website. I've been doing a lot to incorporate my website into my training so that people are using my website as a resource during the training. And so I've evolved it so that I have a page, the course page, and at the beginning, all they can do is grab the course materials. But when they do an exercise and the links for the exercise start to appear and the links for the first impressions, post-it note, virtual board that we're using appear and can engage them better and keep records of what happened.

It's kind of fun. I know you've been teaching for quite a while, and I know that you program some, but does doing this pretty major development of a website give you more empathy for the people who are learning? I mean, you've been learning Ruby on Rails, so, you know, it's the learning curve exists. Oh, yeah. I just have finally figured out how, so Ruby on Rails is built around

this model view controller architecture, and I figured out how to unit test the model part. The model part is essentially the business logic. The controller, I haven't figured out, but I've got some Ruby on Rails experts that tell me, give me some advice on that, and I need some more. I think I'm probably putting the code in the wrong place. So this is, so it has helped me with the empathy because learning how to do this environment where I don't know, well, I don't know the language and I don't know the unit test environment. So when I'm asking C programmers or C++ programmers to try TDD,

they know the language. Okay. That's what their main job is. They don't know the unit test harness. Okay. So part of my role would be to help them learn that and also how to use it. Now I know how to do the testing. I know the idea behind unit tests. But in Rails, it's all different, and so I had to go through that again. So, yeah, the empathy thing is a very humbling experience to do this. I've learned a lot. It's been a lot of fun. I learned more about a website than I ever wanted to know, believe me.

I didn't want to know, okay? But, hey, you embedded people out there, when you're saying interacting with devices, oh, we're special, that's really hard. Yeah, okay. You might be special, but you don't have hard. UI design is not a new problem. You're not the only one that has hard.

Interacting with a framework like Rails is hard, like interacting with some circuit is hard. These are both hard, difficult problems to deal with. Oh, you're just doing websites that easy. Don't fool yourself. That's hard too. So you recently traveled to Estonia and norway to teach classes what was that like well that's it's an interesting place to go it's especially nice to go in the middle of june which one estonia is on the baltic okay so they're pretty close yeah that's part of the

former soviet union sorry for my geography, it's okay. A geography lesson. So Norway's that big one with the fjords, you know, close to the Atlantic. Yeah, you know where that one is. And then Estonia is further to the east on the south side of the Baltic, across from Finland. Yeah. Right. And it was very nice.

People are wonderful there. I had a good group of people. And you went in June. Did you see the sun at midnight? Well, at 11 o'clock it started to go down. It was kind of down in the weather. Down for an hour. And the most odd thing was

at four in the morning when they kicked all the people out of all the bars outside my hotel, I had my windows open so I could get all the nice fresh air and at four it got really loud because everybody just got kicked out it's still bright well it's morning singing yeah it's morning out and that was kind of kind of different but uh estonia was great and then norway there's a wonderful conference there the norweg Developers Conference, very technical. Some conferences have gotten kind of, at least in the agile world,

has been taken over by the business people and the scrum people where they're just kind of worried about the business aspect. But the Norwegian Developers Conference has a nice balance, mostly computer nerds there. So a really good, high-quality conference. There's another one in Bristol, England called ACCU, another really good technical conference. They claim that this isn't the name, but I call the conference the Aging CNC Plus Users Group, ACCU. Aging CNC Plus Users Group.

I know. The organizers go, hey, no, that's not what it stands for. It doesn't stand for anything anymore. But, you know, I look at, hey, I was there. I'm a speaker there, so I can say that. I wasn't casting any aspersions. Did you have to tailor your classes specific for the European folks for Estonia? No. They speak English.

They were aware of test-driven development and such, and many of them had read my book but wanted to go get their questions answered and get first-hand experience. I know that this is stupidly biased, definitely my Americanism showing, but I am pleasantly happy with people who have interacted with all over Europe regarding my book and that they're happy with it and that it is good and happy and all that. It helped them with things. Yeah. Yeah. And, yeah, definitely.

I expected that working with people from China and India because I've worked with those people before, but I haven't worked with a lot of the European community yet. Maybe someday. Yeah. Why not? So you were talking about Agile conferences, which I guess now is the time to ask you about Agile DC.

Yeah. Is it taken over by business people? I've never been to it before. I don't know. But you're keynoting. Well, I know some people there. It won't be taken over because you're keynoting. Well, a few years ago, the London Scrum Gathering,

so the Scrum community does these Scrum gatherings, and the people in London invited me to come and do a keynote. And I said, well, gee, I'm not really a Scrum person. Why would I come and do a keynote. And I said, well, gee, you know, I don't really, I'm not really a scrum person. Why would I come and do your keynote? And they said, that's why we're inviting you because you're not part of the scrum community. You thought you might have something to say to us. I said, oh, so I could say what I think about you guys need to do. He goes, yeah, that would be fine. What did you have in mind? And it was a genesis of this talk I've been doing. And the talk I call, now it's turned into technical excellence.

And I have a few different twists on that. So the talk I'm going to do in DC is on technical excellence. In Scrum, what people are supposed to do is start this two-week cycle as a continuous improvement cycle. And like Chris and I were maybe talking about a little bit earlier, it's kind of turned into a micromanagement cycle. And that's not the intention. The intention is work in two-week chunks, reflect on what you've done, find out what the problems are, and make serious effort to start improving those problems. So the guys that started the Scrum movement or whatever, they didn't define how to do engineering. They thought, well, people are going to discover it's a problem in the incremental, and then they're going to go look for something like extreme programming and backfill it with that.

No one does this, okay, because Scrum is micromanagement these days. Not everywhere. I'm painting a picture, but I think there's a lot of experience of that. There is definitely. And so what my keynote is about is, and it's not tailored just for engineers. It's tailored for people involved in development. And what I want them to understand is, you know, what the intention of working in cycles are and keeping quality high, and that there are things that engineers and businesses should be doing to keep the quality high. And that's around the engineering practices of extreme programming.

And if you're not doing them, you're missing really what the founders of Scrum had intended you to do, is to start a continuous improvement cycle. And the only way you can really reach the promises of, you know, what some people say about Scrum is by cranking the knobs on quality up. You know, they go to 11, right? Turn them all the way up to 11. So it sounds like, I think I remember reading one of the manifesto authors actually kind of came out and said, well, we're doing things a little bit wrong

or people are misinterpreting this a few months back or maybe it was a year ago. I can't remember now. And I don't remember the details. I was going to pull it up, but I couldn't find it. There's been a number of people saying this now, yeah. So how do we, what are the practical steps to get out of misapplying this, I guess my question is?

Well, Alicia, you mentioned, gee, I haven't heard the word extreme programming for a while. There's a bit of a resurrection of extreme programming coming. Now, many of us never abandon it. We just stop calling it that. But now that we see that Agile's been kind of subverted and some of the important parts aren't happening, maybe that's not exactly the right words. Being misused. There's some misunderstanding about what it is.

And so there's becoming less and less fear to talk about it as what's really important. Okay, Extreme Program is a provocative name, which helped get it all started. And then people were afraid of that name. So Agile was a safer name. And then, you know, Scrum became popular because of certification. And, you know, the wrong flavor took over our industry. And so there's a lot more interest in trying to keep the technical practices, keep the quality focus, keep that really high. This is really what the essence of Agile is.

You mentioned the Agile Manifesto. I happen to be lucky enough to be part of the creation of it. And that was a gathering of computer nerds. That was the problem, is that everybody's taking it as business advice, but it wasn't. It was engineering, computer engineering advice. It was software engineering advice.

And so all the things that are left out are not business practices. They're the coding practices. Yeah, the technical practices tend to be practiced by very few. If you went to the scrum.org and found out how many people have been certified in Scrum, you're going to find out it's like 500,000. It's probably where the number is today. They also have a developer certification. It's probably about 50,000. Okay. Now, if those are the right numbers, it means it takes 10 scrum masters to manage one developer. It's a joke. I guess it wasn't that funny, but... It wasn't because I've been in those meetings and that's what it feels like.

I tried not to laugh directly into the mic. But that is what it feels like. I don't know. Agile right now, along with open offices, one of those things that clients say, oh, we do this. And I'm like, and you told me that. That was not a good idea to tell me because that means that your rate just went up. Oh, wait. I shouldn't say that. Well, oops idea to tell me because that means that your rate just went up. Oh, wait.

I shouldn't say that. Oops, you shouldn't put that on the air. I think it's become very buzzword-y, unfortunately, and I think people do just pick and choose little bits of it. Or maybe they start out with what they think is a comprehensive process, but then they start dropping things out as they get lazy. And six months into the project, it's just, we're having a meeting every day and nobody can remember why. And that's where you need somebody who's

a real advocate of the process to say, you know, periodically how are we doing? What things could we be doing differently? And that's supposed to happen in the retrospectives, but it usually doesn't. I've listened in on your retrospectives they're hilarious but not in a good way oh i might have to edit that out i don't think so okay oh by the way my rates do go down if you actually practice test-driven development just in case anybody wondered because I like to get things done. I'm sorry, did we have a topic? I think we were talking about half-assing Scrum.

All right. We are about out of time, and James has been talking all day long. Seems fair that he should get to finish that beer. Do you have any other questions, Christopher? No, that was going to bring us back to the micromanagement, but we did that. Cool. James, do you have any thoughts you'd like to leave us with?

You know, you had a quote in one of your other podcasts I listened to. I think it was the one where you had the guy that does the drones. Dennis Jackson. Dennis Jackson. And the quote was by Shakespeare. Do you happen to recall that quote? I do have that quote because we talked about it over email. It is from Shakespeare. A fool thinks himself to be wise, but a wise man knows himself to be a fool.

When I heard you say that, I thought, oh my gosh, this is one of the things that I've come to realize. As a person that practices test-driven development, I realize how many mistakes I make per hour. I know the kinds of mistakes I make. And if I wasn't following this rigorous practice of test-driven development, which now I don't do because of discipline. I do because of addiction because it's fun. I enjoy it. At first, I thought I was good at programming, but I've come to discover that programming is really hard and that I'm quite frail at programming. I make quite a bit of mistakes. And like I said, I used to think I was good. Most people think that they're pretty good at programming, but they're making the same mistakes I am.

I know this because I watch them program. They make the same kinds of mistakes. So you may not, you people out there that are listening to us, you may not know the kind of mistakes. You can't really see without having the feedback in your face how frail of a programmer you might be. I have seen a couple that don't make so many mistakes, but it seems to be more rare. Yeah. Cool.

I totally agree with that. So. Thank you for being here. Very nice to come and chat with you. My guest has been James Grenning, author of Test-Driven Development in Embedded C. There's a link on the website. He teaches classes in person.

If you'd like to get your team trained on test driven development, go to wingman-sw.com. Or you can get more information about his live web-based training at the same place, wingman-sw.com. Thank you as always to Christopher for co-hosting and for producing, and thank you for listening. We like it when you listen. I have a quote that I would never have considered except James did warn me about the Shakespeare thing. This is from Ray Bradbury, the illustrated man. Pretty good novel. We're all fools, said Clemens. All the time. It's just we're a different kind each day. We think, I'm not a fool today. I've learned my lesson. I was a fool yesterday, but not this morning. Then tomorrow we find out that yes, we were a fool today too. I think that the only way we can grow and get on in this world is to

accept the fact that we are not perfect and live accordingly.