It's all talk until the code runs Ward Cunningham
After the waiter finishes combining four small tables, the group sits down and orders food. They start talking about programming. Someone brings up the meaning of the number 42. You start with your main topic. "So yesterday afternoon, I did a mob session with my team in the conference room."
Oleg, who often proposes to facilitate Mob Programming, answers. "OK! How did that go? "Not very well, actually."
You caught the group's attention. "I'll spare you the endless debates about class and method names. You have to bear in mind that our application is not really what could be called a trophy winner." "Do you mean it's a bunch of mumbo jumbo?" "Not exactly, but it lacks consistency for sure since this code base is actually a merging of several systems." "Oh yeah, those are the worst."
The person who seems to be the most senior, Victor, asks, "What is the worst variable name that you've come across in your career?"
Everyone hesitates. Victor exclaims, "Foobar2!". Laughters. "That one you frame and hang in the building lobby." "No, you leave a little comment in the code: slash, slash we aren't at the circus." "And then, someone comments on your comment: slash, slash, I'd like to see how you would name it!" "Slash, slash, damn it, change this variable name and stop this rotten thread!" "Slash, slash, look who's talking." "Slash, slash, Talk is cheap."
You pick up where you left off. "Well, it wasn't quite like that, but not far off. Heck, if the only issue was naming, we would be fine." "Say more," says Oleg. "Discussions about the variable names were nothing compared to discussions about the design." "Oh." "Twenty-five minutes on the subject of dependency injection and constructors, that's a lot for four people." "Indeed." "As my project manager says, 'you are burning dollars.'" "And where did you get to?" "What do you mean?" "With respect to dependency injection..." "Regarding dependency injection, nowhere. It didn't matter so much, since the code we were discussing is never executed anyway."
"OK! So that stopped the discussion, then," someone says. "You're not going to believe it, but in fact, no."
Oleg asks, "How did you know that the code you were discussing was never triggered?" You say, "It's very simple: we put in a break, we launched the application and it didn't stop at the break."
Another participant blurts out, "Breakpoint Driven Development!"
You begin to feel uncomfortable with the tone of this conversation. Or it's fatigue. You conclude, "In short. It didn't work out as I hoped. If you have suggestions, I'm interested."
Oleg intervenes, "I noticed that in general, code discussions are much more effective when the code has tests. Did your code have any tests?" "No, unfortunately. I mean, we test the application before delivering it, but that's probably not the type of test you're referring to." "Any test is better than nothing at all. But preferably automated, repeatable tests, which run independently of external resources." "So no, the code doesn't have this type of test for the moment. The interest I had in working with everyone was to think about how we could start writing tests..."
Victor asks, "Oleg, why are code discussions more efficient when the code has tests?" "Because with tests, you can protect your code against possible regression defects, while without tests, you are at constant risk of introducing them." "OK, but how does that make the discussion more effective?" "I'm getting to it. Without tests, you can't improve the design, or else you'll be putting the application at risk. You may want to change the design, but you know that this change won't result in operational code right away. Not without a considerable amount of downstream testing." "For sure." "So you find yourself with what you think is a good idea but you can't show it to your colleagues immediately. You feel forced either to convince them or to drop the idea."
Someone adds, "Whereas if you could simply refactor the code while relying on the tests, the code would speak for you." "Exactly," says Oleg. "Since the tests are done downstream of the design and since they are also rather expensive, one tends to wait until a bunch of ideas have accumulated before deciding whether to make the change or not. And it's not effective." "With tests, you can write your improvement right away. If your idea breaks the tests, or if it's not convincing after all, you can undo it very quickly." "Which is to say that when it has tests, the code can participate in the discussion. Without testing, the code does not participate in the conversation." "Exactly. The conversation becomes quite abstract. That's what makes tests so useful when discussing design." "That is to say during a refactoring." "Yes."
You nod showing that you agree with what's being said, "I see. But it's not going to be easy. In order to test the code, we should refactor it. But refactoring code that has no tests is too risky. We don't know what we are getting into and how long it will take."
Oleg agrees. Then he adds, "Speaking of time, your team should try time-boxing what you do during the session. It's a good way to check that we are not going for something impossible, or having a sterile debate, or shaving a yak." "Do you mean: decide in advance how much time we should take for each task?" "It's more like: limit the time spent by the Driver on the keyboard, by setting a rotation every 5 minutes for example. And also rotate the roles, so as to change the point of view and most importantly to bias the team toward action." "I'm not sure everyone would accept this way of working. Then again, this is our first try, I can't really be the judge."
One of the participants remarks, "Developers who have worked alone on their code for years or even decades would be hard put to form a Mob Programming team overnight, let alone an excellent one. If you want this approach to work, you have to give it a little time."
Oleg adds, "And it absolutely must be facilitated. Without facilitation, it is difficult for a group to think together. Some speak too much, others not enough..." "Some are more comfortable speaking in a group. Others wait politely before speaking up even thought their ideas might be superior. Sometimes they give up altogether." "Some are willing to talk but they lack confidence that their ideas will be heard. These are the late speakers." "Then there are those who portend design issues and intervene to prevent the solution from being put in place. These are the early speakers." "Which causes others to insist more, and to counter-resist." "That happens a lot with us. So there is no way to start with something simple. There are objections right away, and we excel at building a bunch of stove pipes." "Suddenly you're building the bridge before seeing river." "Some have side-bar conversations, they are disengaged. They criticize past choices without really offering alternatives. Or they take care of something else on their own screen while making snarky jokes."
The discussion is wrapping up. The faces are gradually fading. Your energy is decreasing.
"In short," concludes Oleg, "if you want your team to self-organize, you'll have to help it along." "I have the impression that Mob Programming works best with teams where everyone gets along well with each other." "I would say it's exactly the opposite," Oleg answers. "Namely, that in my team we get along well because we code a lot together."
It's getting late. You head to the nearest metro. You postpone the decision on whether to try this way of working with the team one more time. Too many variables.
(to be continued) Previous episodes : 1 -- If the code could speak 2 -- See/Advance 3 -- Communication Breakdown 4 -- Driver/Navigator 5 -- Brown Bag Lunch