Pair programming keeps two eyes on the code at all times and increases the ability to communicate to each other about the code. Mob programming extends that out just a little bit to a whole team. So essentially everybody working on the same code, the same problem, at the same time, in the same space and on the same computer. Being on the same computer is what sort of makes it a little bit different than the way a lot of teams work.
Any concept that is going to go into code is discussed, as it is going into the code base. So anything that we want to do, has to be verbalized and so we use this role we call driver navigator. The driver is sort of a smart input device. He or she is working at the keyboard taking information from the navigators, who are discussing how we want the code to look, what do we want the objects to do. And that means we have to express it well verbally. We have to understand it well and everybody is watching it at the same time. So if the understanding isn’t there, that’s clear to us, it’s transparent. So we pretty much go from a good idea to vetting it, to getting into the code base and reviewing the code all at the same time.
Every 15 minutes we change. So we keep this roundory we call it or rotation going throughout the day, where everybody is at the keyboard for no more than 15 minutes. And the keyboard is not the seat of honor. It’s just, you are the current input device and we switch it up, so that you can get back to being a navigator as quick as possible.
The value here isn’t, that I have got an idea and therefore I key it in, it’s I have got an idea an therefore I need to be able to express it. And it’s that forcing ourselves to express it in human terms, that really clears the air. We all get to understand it. There is a lot of benefits to this.
Everybody on the team is a coder. But somebody coming on the team might not be a very accomplished coder, but they’ll become one pretty quickly. Because there is this concept of continuous learning that happens and it accelerates your learning. So if you kind of can code a little bit, you’ll become better very quickly, when you work in this situation, because you are constantly exposed to a good way to do your work. All the shortcuts become apparent, all the IDEs we work with, the coding conventions, how code itself works, it’s all exposed and shown continuously. So when you are working alone, you often go: there must be a shortcut for this. You search around on the internet, you don’t know the right keywords to find it. Here you just ask “Hey, is there a shortcut for this”? Or you see someone use one, you go “What did you just do there”? And, we learn quickly. So we’ve got a couple of guys on the team who really started out in the QA world and a couple of us, who started out more coding, but we all have to code and we all have to do QA on this team. So those with the QA skills have become much better coders and those with the coding skills have become much better QA people.
We all get in about the same time, eight o’clock. We spend an hour studying every morning, then we work the rest of the day till five o’clock and then we go home. During the day, we are interacting all day long and as often as not we take a hike at lunch together. We could pass a sandwich shop on the way and pick up something, but our hikes aren’t just a little walk up and down the street, we are actually getting into some hilly areas, dirt trails, and we all seem to enjoy it.
The basic idea though is that, if we’re turning out code and we are delivering projects, everybody is happy. It’s way more important to see that code in use, than anything else. So, it’s kind of a problem, when we see two or three people huddled around doing the same thing and we think, maybe they are redundant, we don’t need them all doing that same thing, but the results are what counts. And I think my manager or my boss, once he saw how serious we were, he just supported it 100%. It didn’t take him long to see that. A matter of fact, can I tell a little bit of the story of how we started doing it?