 Welcome to Agile Roots 2010, sponsored by Version 1, Rally Software, Vario, AmirSys, Agile Alliance, and Xmission Internet. What we learned in 8,829 hours of pair programming by Keely O'Pelt and Ted Lair. Alright, let's get started. So I'm Keely O'Pelt. My name's Ted Lair. And we're from Menlo Innovations in Ann Arbor, Michigan, and we are a custom software company where we strictly do agile developments, particularly extreme programming. And the title of this is what we learned in 8,829 hours of paired programming. So Keely and I, we weren't paired together for that whole time. We weren't paired together for all 8,000 hours, but we do switch pairs with everybody else in our company. Ted and I have both been with Menlo for about six years. And so what we're going to tell you about today is a little bit what it was like before we started pairing. What it's like while you're pairing and what the different stages are, what the first day is like, what's two weeks like, and so forth. And we're going to try and make some conclusions around that. Okay, so we're going to do a quick survey. Everybody please stand up. Stand up. Stand up. If you have paired for eight hours or less, less than eight hours, sit down. Okay, if you have paired for 80 hours or less, please sit down. 80. We're just going right down the list. 800. 800 or less? 800 or less. Six months. Six months. All right. Can anybody say, can you say 10,000? 8,004 years. All right. So we have a few people left. Good job. Good job. All right. So in a previous life, I worked for a few other companies. I worked for a small, especially hospital in Ypsilanti called Forest Health. Worked for a large consulting company called Commerce One, which is no longer. They went to Falkington, the bubble burst. And I was a consultant at Ford. I actually came to Menlo Innovations right out of college. I went to Michigan Tech in the upper peninsula. I got a degree in computer engineering. Had never really heard of this pairing thing, this agile thing. I had no idea I was fresh, but I did know that I was excited about it because I came to realization that I didn't really want to sit in a cube for the rest of my life. And I wasn't sure what I was going to do about that. Also in my summers and almost the summer after I graduated, I worked for a technology camp for kids where I was teaching them to program and to do stop motion animation and all of those things. So before pairing, did team members openly admit their weaknesses and mistakes in front of everybody? And I can answer this question with a resounding no. When I worked for Commerce One, we were a consulting company. We were supposed to be the experts, so you were not supposed to say you didn't know. You were supposed to have the answer. And when I worked at Forest Health, you got yelled at in front of everybody else if you were wrong. Which is why I don't work there anymore. And while I'm fresh and didn't have too many corporate experiences, this is kind of what it's like in college. You don't want to know that people know that you are not smart. You don't want people to know that you can't solve the problem. So you can only admit your weakness in front of people that you trust, that you know that they won't use it against you. And in places I've worked before, that was not the case. Were team members passionate and unguarding in their discussions? Do they speak their mind? When I worked at Ford Motor Company, no, you did not speak your mind. At least not in the meetings. I had a friend of mine, a co-worker that I worked with, and we used to blow off steam together, complain about everything else, but you didn't do that in the meetings. You did it in private. So when I was working at this technology camp for kids, we worked with other counselors. There was one counselor that I thought that I got along with. We had good conversations. We worked together well as far as I could tell. Till the middle of the week, about halfway through camp, the director and this particular counselor pulled me aside, and she was trying to get us to talk to each other because apparently this counselor had a huge issue with me. Apparently I was arrogant and I knew exactly what to do and I didn't listen to him and all of these problems that I was completely unaware of because he didn't communicate with me. He just kept it all bottled up, needless to say, since I was young and it was a horrible experience. I ended up crying, I ended up feeling really bad about it, and the rest of the time at camp was really hard to work with him. So if there's no trust then you can't have conflict. You can't argue with somebody about a problem. Did team members leave meetings feeling like they knew what to do or knew what was expected of them? Again, when I worked at Ford, not usually. Occasionally somebody in one of these meetings, when I worked at Ford, somebody would actually say action item and then you knew you had to do that one. But that was the only thing you actually knew. There were several other things that nobody actually called in action items. You weren't really sure if you were supposed to do that or not. You had to figure it out later by going and sending email and talking to other people and trying to decide, okay, why are we there and what are we supposed to do? So without open debate, it's actually difficult to know if you're free or how far apart you are in positions, in your position with other people. If you don't communicate, if you don't directly decide this is what's going to happen, it's not going to happen. And you're not going to understand. You're going to think that the person standing next to you completely agrees with you. And then there was pairing. And it was wonderful. So this is Gary. He's one of the people that just started working at Menlo Innovations. He's an international intern. He's young. He's been there, well, more than one day since we didn't write this yesterday, but he's been there. He just showed up recently. And he's never paired before. So Gary and us definitely experienced a few things on our first day. First day was all about survival. And we did get through it. It was eight hours. We pair all day. You don't get to work on production code without pairing. So we survived. And it's intense. And we learned a few things along the way. A little bit about the development environment. A little bit about the project you're working on and the new language. If there's a new language. But it was exhausting. It was really tiring to be able to sit there and talk to somebody all day and actually work on something. It's extremely noisy. It's not like car crashes or train sourns or anything like that, but it's kind of a roar. So we can experience that right now. If everyone would just turn to the three people next to you and introduce yourself. Good. Okay. Back up here. That is the roar of the factory. It's not any one sound or any three sounds that come out to you. It's just kind of a roar of people talking. By hand, one of the things I felt like was I was slowing down my partner because I was new and didn't know what was going on and my partner had to explain a lot of things to me. This is an example of a pairing style. I wish the pictures show up better. They look great on our screen. We turn the screen around. Student driver and instructor. So this is what generally happens when a new person shows up on the team. One person is the student driver. They're the new person. They're explaining, talking about this, pointing it here, do this, don't do that, all that kind of stuff. And this actually is going to happen when Ted and I go back to work on Thursday. We are starting to dive into the world of iPhone apps. And none of us have really experienced the iPhone apps except our international interns are starting to get on it, which is Gary. We remember Gary from the beginning. And Gary is actually going to be pairing with Ted. And Gary is going to be the driver or the instructor. And Ted is going to be the student driver. Because I've never done iPhone apps before. So... The next slide is Brian. He's been here... He's been at Menlo for about two weeks. He is a programmer, so he's done this before, but due to the recent economic troubles, he decided to go back to school and now he's coming back into the workplace. Work force. But he's new to pairing. Why are you doing that? So after two weeks, the things you realize... Kindergarten skills. Play nice, be polite, say please and thank you. Those are important when, because you're working together, sitting next to somebody for eight hours a day all week, and it's the same person. So those things are important. And first date mentality is something else we like to call it. What is it like on your first date? You are extremely polite. You don't have any bad manners. So that's what it's like for the first couple weeks. You also... Also during the first two weeks, you end up having a lot of partners. Probably two, three, or four, depending on what's going on. And you figure out you need to fight. And not fight in the Put Up Your Dukes and Let's Start a Fight, but have... argue about or discuss how you're going to solve this problem, how you're going to attack this, whatever task you have, whatever story card you're working on. So you start to see that you're going a little faster and that feels good, but you're still thinking, man, I'll be really fast about this stupid process. If I didn't have to pair and I didn't have to write these unit tests, I could be flying through stuff. You still haven't quite figured out that the benefits you gain from those processes are way better than going faster. And it's still noisy and your brain still hasn't quite figured out how to filter out the dull roar of the factory from when somebody's trying to get your attention. That takes about two or three weeks, so you're just about getting used to the fact that it's really noisy in the factory. And it's kind of fun, kind of gotten through two weeks. You're starting to build some trust with the other programmers, and you're starting to feel like it's fun and you're solving problems. So we talked about this a little bit, but a good parent partner knows all about kindergarten skills. This is the slide about all I really needed to know I learned in kindergarten. And it talks about things about, like we talked about before, say please, say thank you, don't run with scissors, no biting, no kicking, no screaming. And actually, when we were putting our hands together, we'd actually never taken the chance to read the whole thing. And at the bottom, it's hard to see here, but you should take a minute later on to read it, it says, and it's still true, no matter how old you are, when you go into the world, it is best to hold hands and stick together. That's what pairing is. You're sticking together. Divinia and her partner, Divinia is another international intern and she had been here for two or three weeks, so she was still fairly new and she was working with her partner and she accidentally dropped the production database, the whole thing. Gone. She leaned us to say she was a little worried that she was going to get sent home and she was really worried she was going to get fired. You could see the panic on her face. She's like, oh my god, am I fired? What's going to happen? Her partner said, no, no, no, it's okay. You're not going to get fired. We can fix it. It's okay. In fact, I think he even left. I think, and when the rest of us who were working on that project heard this, we all sort of had a chuckle and this really confused her because at least one of us had also done the same thing recently. And we said, don't worry. Don't worry. In fact, your partner was not entirely sure how to get it back, but he knew we had a way of saying the table said, here's the scripts. Here's what you need to do. In 10 minutes, we had it all fixed. And it was all back and we told her again, no, no, no, you're really not going to get fired. It's okay. Jody. So this is 800 hours later, about 6 months. About 6 months. Jody is a sequel guru and a hero programmer. He's actually one of the client programmers. We do projects with clients and so sometimes they send over their programmers. Jody is used to putting out fires in his organization. He's the guy that fixes everything in the middle of the night. Yeah. He comes in at 7 a.m., leaves at 5 p.m., has a phone, has a pager, checks his email every 20 minutes, that kind of guy because if something goes wrong, they call Jody. And when Jody got into our space, he wasn't really certain that this pairing thing was great and wonderful, but he had an open mind and we appreciated that. And he started doing it. And he did it some more and he said, man, I'm actually getting things done. He's like, yes. That's because you're not fighting fires every 10 minutes. And he really liked it. And he actually enjoys writing software again. He was so used to fighting fires, he had forgotten what it's like to actually sit down and write software and produce software and actually make progress. So after 6 months, some of the things you figure out, non-verbal communication is very important. And you're still trying to figure, you know it's important, but you're still not quite sure how to do all of the things and decode all of the non-verbal signals. But you're getting there. And you're learning more. You're picking up on new techniques, new patterns, new languages, new syntax, things that you didn't know because you didn't get a chance to explore those things. And you're also learning how to work with different people because different people communicate in different ways. So you're increasing your mentoring skills which you're going to need when you get to 8,000 hours or 9,000 hours or 10,000 hours. And you've been slowly building trust with some of the other team members, some of your other pair partners that you've been working with over these past 6 months. And you still don't have that faster feeling. You're still like, I am going slower than I know I could go. But you're starting to come to that realization that that might be okay. That the team is actually producing things. You've seen features and functions get done. And one of the other things you learned about now is there's some people that really annoy you. People don't always get along. We get this question a lot. What happens when people don't get along? Well, first thing we say is it's only one week. You can do anything for a week. We do week-long iterations. We change the pairs at the end of the week. Second, we remind people that probably for that week you need to be on your best kindergarten skills and most polite behavior. And finally, don't forget that you should argue about the technical problem, not about personal problems. Not because you just really hate that that person is always right. Because that happens. But what is the best solution for the software? And this, make no mistake, this is really hard because if you're in the middle of an argument, it's you really just want to slam them. He's nodding. It's really hard not to do. So, a little story about this. We have John and Thomas. They are assigned a bug. Now, our bug cards we actually make story cards for our bugs and they actually get planned and prioritized by the customer on to the planning game. So, in their lane they have a bug card. They start out the morning and Thomas comes up with an idea. Convinces John that this is the best idea and that they need to try it. Well, eight hours go by and this idea has not solved the problem. The bug is still there, the tests don't pass and John went along with the plan but it really was Thomas's idea. So, in a normal situation, what might happen is John will lay all the blame on to Thomas because it's Thomas's idea and throw Thomas under the bus. But when you're pairing, you are in there as a team. You're going together hand in hand to solve the solution. So, what did John do? John said, that's okay. We tried it. We figured out it was wrong. Here's the next idea. Let's go. And they just kept working on it and eventually solved the problem. Another pairing style, we call driver navigator or other people call driver navigator. This is more like what happens after you've been doing it for a few months. There's less of the instructor always pointing and saying what to do and more of the both people actually know what to do. They know where they're going and one person's typing and sort of in the moment of what they're doing and the other one one person's typing and the other one sort of keeping track of where are we going next? What are we going to do next? And they're talking back and forth about how they're going to solve this problem. I just want to point out in this picture you can't see. What's happening is Ian on the left has typing and Ted on the right is pointing at the screen. Ted is the navigator and Ian is the driver. Just so you can get a clear picture of what's going on. And we switch roles throughout the day depending on who feels like typing or who gets tired of typing or who gets tired of navigating. You just sort of slide the keyboard over to the other person and say you drive for a little while or if you want to see a better version of this picture it's actually the Wikipedia picture for a pair of programming. We didn't do that. It just appeared and we were googling actually and there it was. It's like Ted, there you are. It was a shock to me and Ian. Hey, you can't even see where the picture is. It's me. 8,000 hours. Where are we then? I love extreme programming. Love it. I love pairing. I love everything. I think I'm ruined. The partners often come to me like you're never going to be able to work anywhere else. It's just not going to happen. And there's a little thing in the back of my head going, oh crap, they're so right. So I learned a lot. I have a really firm grasp on design patterns. Go ahead. Absolutely. Sure. So let's talk about code ownership. Ownership. It's my code. Don't touch it. I'm going to put up booby traps and razor wire and missiles and everything else. Don't touch it. It's mine. And when I go on vacation you're sunk because you can't work on it. It's so cryptic that no one else can figure it out. It's my way of job security. Code storeship is where everybody owns all the code. Nobody is responsible for only one piece of the code or one module in the code. Everybody shares all the code because with paired programming there's actually two people writing the code. So now you're at least sharing it with one other person. The fact that we rotate partners and you get different story cards and we move people to work on different parts of the software code throughout the whole project. Everybody sort of works on all the different pieces or all the different modules in the whole project. So nobody has a chance to build all those missile turrets or gun towers around their code. And I think the best example of when this works is when you get into a piece of code and you go I don't understand what's going on. Let's start re-factoring method names and variable names and make it more clear because if it's not clear to me it's not clear to the next person and you have no fear of doing that. No one's going to come to you and be like you changed my name. That was the best name ever because that's just not going to happen. Yeah. So we get asked this question a lot and most people ask how long does it take to come up to speed? And most people in the factory will say 20 minutes because the way we get people up to speed is by actually doing it. Have a story card, have something you have to figure out, push the keyboard in front of the new person and start telling them where to go and what to do. And soon you'll be telling them less things of where to go and what to do because they'll start to figure it out. And you have to remember you don't need to know the 5-year project in 20 minutes. You need to know the section you're working on. And then the next day maybe you get to learn a new section and you figure out how to collaborate and the following day and the following day it continues. So what's really happening is we're sharing knowledge about the software with the new person. Right. And so we're not wasting time, we're investing in knowledge sharing. Does that help? We would never go that long. It's probably 2-3 weeks. Yeah. So we try not to swap the whole team from all the developers from one team onto a new project at the same time. That's just a little silly. Correct. So what's it like at 8,000 hours? Well, one of the things that I think is still a challenge but what we're getting better at it is changing your communication style. You figure out that I can't communicate the same way to every person I pair with so you have to start changing your communication style. Do you need to be direct? Do you need to bring them along by making them think that it was their idea? I mean, how can you most effectively communicate with them? Ted's... Ted is a different communicator than me. I'm very direct. I'm not. I tend to ask a lot more questions, try to lead them to the right answer to the answer that I want them to come up with. Sometimes that works really well with some people and it totally falls flat because they will not give me the answer. And something that Ted does that I can't do is he will let people hit walls. It's one of my favorite tricks. Right. If I know it's not going to work, whatever solution we're going to come up with, I can try and argue with them that, look, it's not going to work, it's actually much easier and faster to just let them do it. They'll figure it out in half an hour or an hour and we could spend arguing about that that whole time, or we can just let them do it and they'll figure out, oh, this really isn't going to work. Like, great, it doesn't work. Something else you figure out that you're starting to do better is getting into the... We're calling it the pairing zone. So you can start and stop quicker. There's a lot of interruptions when you're working in a team. In fact, that's one of the rules in our house is if someone interrupts you for help, you have to stop and try and help them. Well, at first, that's really hard to figure out of working, but after four years, you're getting pretty good at it. You need feedback. You need to know how you are communicating with the other people, what your working relationship is like, how you're working with all the other people, all the other people on the team and all the other people in the factory. But it's really hard to give feedback to other people. You start to want it and you need to get better. But then you realize that you have to start giving it back or else it's not fair because no one else is giving feedback. And that's really hard. It's hard to share. But at this point, you started to build trust with your teammates. And there's one guy at work, Rob, who... We all have kind of a hard time working with Rob. Rob is direct and he can be direct and he can go around in circles. And it always seems like Rob wants to have the answer, but he wants you to get to the same answer he's at. And I've told Rob before, the other day, last week I was pairing with him, I said, Rob, you're not telling me what you're thinking. You need to do that more. And it was frustrating and he could tell I was frustrated but because we worked together and we trust each other, he took that feedback and he changed a little bit. Now, did he change forever? No. He changed every day. And if I remind him about that later, maybe he'll get better. You also learned how to fight well. How to have arguments about the code or about the architecture or the problem you're trying to solve. And you've learned not to fight with the person but argue about the problem. So the best way about this is we have Jeff and Gabe. Jeff and Gabe are at the whiteboard and we're calling it a lively debate. They're going at it. They're going at it about some solution that they're trying to figure out for a problem. We happen to have the client of that project in the room happen to be visiting that day working on his computer and he's kind of observing this from the background. And suddenly it's noon. I don't know why, but all developers like to take lunch at noon. It's kind of weird, right at noon. Everyone just kind of stops and goes, have lunch. And it's kind of like the bell rings. Ding. Jeff and Gabe put down the markers. Say, hey, let's go to lunch. And walk off to lunch together. And have forgotten about, seems as if, they have forgotten about this lively debate or argument that they're having. And the client's jaw hit the floor. Because they stopped. Because they stopped and he kind of came up to, I think he came up to James who's standing in the back. And said, what's going on? Do we need to worry about something? How comes no one's stepping in? And we're like, no, it's okay. They're having constructive conflict. And then one o'clock rolls around. It's almost like the, you know, the buzzer goes off again, ding, time to work. They get right back at it. At the whiteboard, arguing about the architecture. Ping-pong. This is another pairing style that we do. Let's describe the pictures first. Okay. It's hard to see. On the left and on the right are both actually Gabe and Thomas. And in one picture, Gabe is typing. And in the other picture, Thomas is typing. And what they're doing is one person is writing a unit test, a failing unit test. And then they slide the keyboard over to the other person who makes the unit test pass. And then that person writes a failing unit test and then slides the keyboard back. And so you just sort of sit there back and forth playing ping-pong with the keyboard, and then you slide the keyboard back and forth. And it's just like a game, as we were just learning about. Right? It's how many lines of, how few lines of code can I write to make your test pass so that you do have to write a better test? So let's revisit those questions from the beginning. And let's think about it from the pairing point of view. Now life as pairing. So do they admit weakness and make mistakes in front of the team? Do the teams leave meetings? Confident they or peers are completely committed in decisions that I agree upon, even if there was initially a grist agreement. And Ted and I thought about this, and we didn't have to think very long. And the answer is completely and a resounding yes. This is the way it is. And the reason for that is trust. We have spent a lot of time and a lot of work building up trust with our pair of partner members on the team. This comes from the five dysfunctions of a team. This is Patrick Lanciani's book. And you can see that the trust is the foundation. It's the one on the bottom. If you don't have trust, you can't have constructive conflict like Gabe and Jeff were having when they were going at it at the whiteboard. If you haven't read this book and you have a team, I highly suggest it. It actually is a quite easy read. At the bottom you can't read. It's not dysfunctions of a team, a leadership fable. It's a story. It's easy read. It's not like academic. And those questions actually come right out of his book. Those three questions. And just to go one more step up on the triangle, as we were talking before, if you don't have trust, you can't make it up to fear of conflict. And these are the dysfunctions. So it's fear of conflict. But with trust, you can have constructive conflict and then it goes on from there. The only way to do this is to practice at it. We do this every day, five days a week, eight hours a day. You're sitting next to somebody. You're sitting next to your paired partner. You're working with them on a task. So we practice it all the time. And we practice it with different people because we switch partners every week. And occasionally we switch partners in the middle of the week if we have to solve some special problem that we need somebody, a specific person's help. We'll engineer a prisoner exchange with another team member or another pair. Like I'll trade you, Keely, for an hour if you give me game because Keely knows something about the problem they're trying to solve. So we want to leave you with, you can pair two. It's your action item. If you're not pairing now, try it. That an pairing might seem like it's overwhelming and daunting. Well, how many times have you pulled someone over from another desk and say, hey, could you read this email before I send it out? Or could you help me find something in the code that I know it's here, I just can't find it? That's pairing. It's just short little bits of pairing. Extend it. Make it longer. And the picture you can't see, which I wish could, up in the right-hand corner is a big table of snacks. Oh, yeah. We all know that developers work on their stomachs. And sugar. And caffeine. This actually is a picture from our founder's original Java factory, where they actually enticed people into the location where they were going to pair with a giant table of snacks. Do it. It's fine. The rule was you could only eat the snacks if you were actually working with a partner in the Java factory. So that's how they got some of the people in there. All right. So we have about 10 minutes left. We personally did this for questions. And how do you see the program? The question was have we implemented paired programming with people that weren't physically in the room? We have done this experiment. We, as we mentioned before, we have international interns that come and spend time in our space anywhere from six months to 12 months. And so I want to preface this story with, I don't think this would have worked if this person hadn't been in our space for 12 months. But a couple of the interns went back to Copenhagen and we were down on resources. And we really needed a couple more pairs. So we called them up and asked them if they were willing. And they were. I think we were skyping. I don't remember anymore. But heads out with microphone and a shared desktop. So the code and stuff was on the computer in our room but they could see it on their screen and their keyboard and mouse worked. And at first it was I don't want to say difficult, but you have to figure out the logistics between you and the other person over on the other side. You know, you have to communicate verbally. A lot of us communicate with our hands, with drawings, with, you know, nonverbal communication. You have to tell them here's what I'm thinking, here's how I think we can solve it, here's the test I want to write and you have to agree upon who's about to type or say, hey, can I grab the mouse for a minute? I want to show you something. So we have done it. It works. But only I think when someone, when you have already built trust with that person. So the question was, do we have anyone that comes into our space that had a really horrible experience and has negative outcomes, right? Oh, had it negative before coming to us. So they didn't enjoy pairing and then came here and now they do. No, I don't think so. I don't know of anybody like for that. So we, the question was we have everybody sharing keyboard and mouse. There's not two. He wanted to know if we've ever tried an experiment where we had two keyboards, two mice. We haven't purposely tried the experiment, but we did have a client come in that had some carpal tunnel issues and couldn't use a mouse and he brought a pad in with a, you know, like a pen and that's how he moved the mouse and it worked fine. I mean, you're sitting next to him communicate and say, here's where I want to go. Here's what I want to do. Okay, I'm going to do the mouse. Like, it's fine. Besides, I mean, you could see his name was Jason and you know when he picked up the pen and went like this to start writing you knew he wanted to start typing. Yeah. So you let him go. There's no reason why not. There is sort of a space logistical reason. Two keyboards are wider than one and we're sitting at a five foot table with one, you know, one computer, one monitor, one keyboard, two people. So there is a little bit of a space constraint. But they're not really. So the question was how far out do we plan our pairings? Like who's going to pair with who? So at a personal level I wish we did it farther out. At a company level we do it the Friday before. And I think the person, we have a person called the factory floor manager and she definitely starts working on it Wednesday, Thursday, Friday, but she doesn't get finalized until Friday. A lot of that is because when our clients come in some of them get to decide how many pairs they want on and they might change their minds. So it's kind of in flux until Friday afternoon. Human logic. Carol who's the factory floor manager talks to the project managers and they all figure out how many resources does the Dawson project need? How many pairs does Izzy need? How many pairs does Ovis need? And they figure out how many total people they need and then they figure out how many people we have. And then they look at the current schedule so they try not to pair the same people again. And they sort of just figure it out. Who's going to work with who? Who knows who are we going to swap between Ovis and move them over to Dawson to try and rotate some team members through their other projects. Who just got moved in because you don't really want to move the person who just moved from one project to the next and jump them to another one unless there's a really good reason. So the three or four people just sit down and figure it out. I wish there was some really cool algorithm but there isn't because there's so many human factors involved about who's been on the project, who hasn't been on the project, how many people do we need, when do people have appointments like there's so much? In the back? The bullpen? Is that what you said? Open and collaborative workspace? No. Not if you have a whole team of people pairing. If it's just two people pairing and that's all that's on the project. Sure. Yeah. You could pair and you can collaborate with the person sitting next to you but you're going to really miss all that collaboration you're seeing going on around you and you start to be able to filter what other people are saying. So we might be typing along and doing something in the printing function and suddenly the pair across the table says oh we're about to touch printing and suddenly I perk up and go you're touching printing. I'm doing printing. What's going on? And you would miss those things. So I misspoke when I said no. It's better than doing it alone. Yeah. If people need to use the restroom or get a coffee or whatever absolutely people go do that but there is a politeness factor where if you're gone for like 15, 20 minutes that's a problem because you're not supposed to be working on production code if you're not paired and we do time sheets where we measure or we keep track of what we're working on for the client in 15 minute increments. If you're gone for 20 minutes and you're not working I feel really bad billing the client for that time. I can't do that. So yeah and it's not like the bathrooms are you know a huge walk away or the coffee is a huge walk away. Sure, five minutes you need to go get a coffee? Great, see you in five minutes. But we also have our 10 o'clock stand up meeting so everybody in the factory stands up we pass the token around you talk about what you're working on, who you are what project you're working on. That takes 13 minutes so there's a break right there sort of a natural break yeah that meeting takes 13 minutes whether there's 10 people in the room or 50. It's amazing, we don't really know how it works we're not sure how that happens and in the afternoon the developers one day instituted walkies where all the developers stood up at three o'clock and walked out the front door, walked around the block came back and sat down and we didn't tell the boss and we didn't tell the project managers walk right out the front door. It was fun. You can ask that guy James right there what their reaction was when they saw us all and it's now we do it every day somebody says walkies usually it's Jeff and we all go oh yeah great and we all get up and walk around it's five minutes like your blood flow gets going you put down your problem something happens when you put down the problem then when you come back and you pick it up again you have the answer. I don't know why it is but you must send an email to out at menlowinnovations.com the question was how do you handle time off and a factory floor manager Carol she keeps a Google calendar and puts everyone's names on it when they're going to be out and she looks at it the next week and if there's not enough resources because there's too many people gone she will bring in more people we mostly have a lot of subcontractors so the subcontractors ebb and flow depending on our needs and we only have ten full-time employees ten? I don't know something about ten yeah so subcontractors is the real answer so we're running out of time so a few more questions you've asked too many we're happy to talk we're happy to talk to you afterwards he's asking do we get increased productivity does it go up to double because we have two people and the answer is no and that's actually not the point the point is to have better communication, better knowledge transfer better code review, less issues later on find mistakes faster actually I have another presentation about this called overcoming Brooks law we do that there's a paper on our website you're welcome to go read it it's free it's not less than the productivity is not less than one we don't slow down faster overall the team goes faster last question this guy's been having his hand up for a while that was your question last one in the corner John's a good example the question was about employee turnover what's it like John is a great example of employee turnover John's one of our subcontractors if there's no work for John he goes and finds a gig somewhere else and then after a few months or several months he calls Carol and says hey you know my gig's up is there any work and if she says yes then he's great he'll come back and work for us if not he'll re-up his current contractor go find another one we're happy to talk anytime the rest of the day we'll be here for the rest of the day of him his time so thank you very much