Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the pain of of not having ethernet cabling tools for the single cable in the house that needs some work.

[00:00:34] Dave Adsit: I'm Dave Adsit, a VP of engineering, and I have been thinking about developing the skill to do the simplest thing that could possibly work.

[00:00:43] Allan Stewart: Our topic for this episode is collaborative coding. Now, before we get to the coding part of that, I think the first question we should ask is why would we want to collaborate in the first place?

[00:00:55] Dave Adsit: Well, I would start by saying collaboration is one of the fundamental ways that humans accomplish things bigger than themselves. So there's a lot of reasons why we would want to collaborate on a software project. I mean, if you want to get it done faster, if you want to get something done that's bigger or more audacious, if you don't have skills, if you're developing a deeper understanding of something that you only have a surface level. So I can think of a large number of reasons why, but I think we kind of boil it down to a quip, right? Two heads are better than one.

[00:01:36] Allan Stewart: Yeah. And when we're working together on a project, especially in the context of in a company, I think it's inevitable that you have to collaborate at some point. Otherwise, it's just some form of anarchy, right? Everybody's doing things on their own, independently, oftentimes at cross purposes, and it causes problems if there is zero collaboration.

[00:02:03] Dave Adsit: Yeah. I was sitting in the airport a few years back and I was thinking about all the things that go into running an airport. I was just kind of watching the people. I was watching, you know, the food vendors and the magazine vendors and the security personnel and the different people working at the different gates and the people who are outside the windows. And I was just kind of sitting in this spot watching all these people because I was there for a little bit. And I was thinking about how it would be impossible to do modern air travel at the scale of one person or even the scale of a small software team. If we say you've got a team of eight people, you can't accomplish air travel with eight people. You know, there's eight people working on the plane when it's in flight. So your whole flight crew might be eight. I mean, maybe it's only five or six. I don't know. I haven't counted every single person working for the airline on every plane, but you can't, there are some, some tasks, some things that need to be done or that we want to be done that are beyond the capability of one person. And so as soon as you start, start working with multiple people, now we have to start thinking about how are we going to collaborate? How are we going to work together on this?

[00:03:27] Allan Stewart: Yeah. And ultimately, that's what collaboration is about. How can you have more than one person working on a thing? And if you have a group already, like a company, well, then you already have multiple people trying to work together to make the company successful. And so you need some level of collaboration. Recently I read a blog post that was very anti-collaboration, and in reading it, it was very apparent that the idea or definition that they had around collaboration was very different from mine. What what was discussed in this blog post felt very much like committee rather than collaboration, that it wasn't about how can we work together effectively. It was all about, I'm so tired of every single person having, you know, if I'm in a company of 50 people, then I need 51 votes to get anything done. And that is not the same thing in my, in my experience.

[00:04:37] Dave Adsit: Yeah, I, I have to agree. I think that if you're doing design by committee, you're going to run into trouble, right? What do they say? "A camel is a racehorse designed by a committee." So good for very, very long races across the desert. Right. So everybody, if you don't have a good decision-making strategy or a clear vision, then collaboration is just going to feel like wasting time talking. But if you actually have have a clear vision and a decision-making strategy, whether that's democracy or some form of hierarchical decision-making, you are going to be able to leverage the skills of different people to accomplish a task bigger than any of you. Um, but if you just walk into a room and you try to be purely egalitarian and you have have 51 people at the company. Now you're going to have to try to convince everybody. So collaboration does not mean consensus. In fact, consensus is often the worst way to make decisions or to move an organization forward. We want alignment, and collaboration requires alignment or creates alignment. It's kind of a circular pattern, right? The more we collaborate, the more aligned we become, and the more aligned we are, the easier it is to collaborate. But we don't need to have consensus to be collaborating. We just need to have a common vision and a common goal.

[00:06:17] Allan Stewart: So there are a bunch of skills that are related to collaboration generally. Anything from how you do your team meetings, how you work with your product manager, how you interact across teams in a company. But in this episode, we're going to really focus in on collaborating in code. And as I've thought about collaborating in code, I've given this some thought and I'm kind of, I've come to think about it in a spectrum from low to high collaboration. And so at a low level of collaboration, I'll see teams or companies that have a shared code base. And oftentimes that's the extent of their collaboration. In, in code is that, oh, well, here it is, here's the shared code base. And so various people will make changes and sometimes they're stepping on each other's feet. Um, a lot of merge conflicts happen when the only collaboration you have is, well, this is what the code looks like now. And, you know, this is what is current on, on the main line.

[00:07:27] Dave Adsit: Well, and I have a really good solution to that. What you really need is better documentation. Right? So when you talk about collaborating in code and code is the mechanism for collaboration, I think that I, you know, I've experienced this. I've worked in organizations that were like this. It reminds me of the book, The Cathedral and the Bazaar about open source software. You know, every, in the, in the bazaar, everybody kind of comes and goes and they can all set up whatever little area they want. There's not in a, in a bazaar, there's not a lot of, not a lot of structure or that there's structure that supports many different strategies for getting things done. And so the idea that the only place that we have to collaborate or the only way we are collaborating is by having a shared code base. It has to be the lowest form of collaborating on a software product. It's like you're barely collaborating at all when that's all you're doing.

[00:08:27] Allan Stewart: Yeah. Oftentimes, there will be some additional collaboration that is happening at a verbal level. You've got your stand-up meetings where people are talking about what they're trying to accomplish and what they're doing, but what I found is if you don't really get into the code that somebody else is working on, you're not gonna, you're not gonna understand it. You're not gonna spend, if you don't spend the time at least looking at and trying to understand a piece of code, then there's just too too much detail in the code, right? Code is so exacting that you just kind of have to take it with blind faith and say, "oh, well, I hope they know what they're doing." Because the only time that I'm going to find out for sure is when I have to run into some piece of code that they wrote for something that I'm doing, if that's the only level of collaboration that we're really

[00:09:23] Dave Adsit: doing. Yeah. You end up seeing a lot of standups that look like each person doing a status report poor and ignoring the rest, right? Because it's irrelevant what you're working on because it's not what I'm working on. And you end up seeing a lot of PR reviews where, you know, if you've decided as a group, somebody has to review your code before it goes to production. Well, the reviews are going to be very superficial. They're going to have a lot of "looks good" or "this is fine" or, you know, very, very minimal feedback on the code and very often an assumption that it works. And then you're going to have to put in place other strategies for ensuring things like quality. So a team that's doing this type of collaboration is probably going to have some kind of formal QA function, which is separate from the development function that is validating that all of these people who are working independently produced something that kind of works together most of the time. Right. So this is, I think, a very common strategy that I saw 25 years ago. The teams that I worked with 20 to 25 years ago were often following this kind of very low collaboration style. And I know there are teams who still do it today. It's not to say that it's gone from the industry, but we've developed a lot of additional strategies for collaboration. And people have developed higher level skill at collaboration. And so we're doing other things now. Yeah.

[00:10:55] Allan Stewart: And you mentioned code reviews. That is one of the things I think that helps. But to your point there, sometimes they're just... If the person who's doing a code review isn't really reviewing the code or isn't really digging in, doesn't give much in the way of feedback, it's just kind of a thumbs up, looks good to me. They're not going to have the same level of shared understanding as if they actually went through it. And so pull requests in some cases, I feel like are sort of like capitalism. It's the least bad bad idea that we've had so far. I think that's, I'm butchering like a Winston Churchill or somebody, but the point stands is I think that a pull request, it's better than not doing it. It's better than not having the code review. It is an opportunity to work, and it's the least bad way that we've figured out to do shared code ownership if everything is asynchronous and there's, there, and you're not going to have any other level of collaboration. And so it can be a very, very low level of collaboration. I've seen it be higher, even though we're doing asynchronous, but it can be very time consuming. And at that point, you can very quickly start getting to the point where the people who are doing the code reviews are spending as much time as the people who are doing the initial development and the amount of rework can be very, very high in those scenarios.

[00:12:39] Dave Adsit: If you're working in this strategy, I highly recommend reading The Cathedral and the Bazaar and seeing how it applies to your group, because you're going to find things in there like the concept of a core team that is responsible for the quality and the vision and the direction. Maybe that's your architecture team, maybe that's, you know, just the people who have been around for the longest, and they're always reviewing everybody's code and rejecting a lot of it. So you've got, like, your core team, which is a much smaller set of the total people working on the system, and they, they act as the gatekeepers or the guardians. And then you've got all your unwashed masses who are submitting things and hoping that they can get past the, the, uh, the the core team and get their code into production so they can consider their feature done so they can move on to the next one. So there's a lot of strategies that we've developed as an industry for working in this way, and it can work for certain projects. I mean, it did work for a long time on a lot of projects. I just feel like we have developed additional mechanisms for doing it that are going to get better results in general.

[00:13:48] Allan Stewart: Right. But to move beyond this ceiling, I don't know if you can do it asynchronously. At least I have not seen a way to make it happen. If you're determined to work independently, if you're determined to work asynchronously, that we're not actually working together, then I think that that is kind of the ceiling. I was like, "oh, well, that's as good as you can get." But what's beyond that ceiling? For me, the next step in that gradient is what I've been calling parallel coding. I've been thinking about this and I probably have a different definition, but I first started thinking about this when the term was presented to me by the guys over at the Mob Mentality Show. And I'll start off by saying that I think about parallel coding that you are are in the same room together, that might be a virtual zoom room or, you know, screen share of some kind. Um, but you're working together. You're in parallel, which means that each person is working individually, but you're working towards a common goal. You are able to quickly share screen. You're able to have high bandwidth communication at an instant where I can just say, "hey, I have a question. Hey, I'm working on this. Could you give me some suggestions?" Or, "hey, I would like a code review on this code that I'm working on" and be able to get just-in-time feedback, just-in-time synchronous code reviews where during the code review, somebody can say something like, "oh, yeah, but that name doesn't make sense." And we rename the thing on the spot thought rather than waiting for a asynchronous code review, which at some time later, I'll hear about it and say, "oh, that is a good idea." And now I'll do the rename, but it's after I had already kind of moved on to something else. So, um, so yeah, the, the, the thing that really makes this work, in my opinion, is that you have to be working towards a mutual goal, which means you're You're probably working on the same feature or you're working in the same area of code. Because if you're working independently on different things, you get those same problems that we had in those lower levels of collaboration. Because you're not really working together. And so if you can do a just-in-time code review, which is nice. It's more expedient than a pull request-based code review. You, but it's still hard to get the same level of commitment. But if we're all working on the same feature and maybe we've divided it up and we say, "oh, you know, Dave, could you do some of the database work and the API work?" And I'm going to do the front end work of this same thing. And then when I have a question or I say, "hey, I want to show you something," you're going to immediately understand a lot more about what I'm doing. And little things will pop up much easier. Like, "oh, were you planning on me returning an entire array of these objects?" "Oh, okay. I thought we were just, you know, you're going to query for them singly or something like that." Those kinds of decisions that can matter a great deal, you immediately notice because your head is in that same space already.

[00:17:16] Dave Adsit: Yeah. So when you first proposed parallel coding as the parent of young children, I I thought of the developmental stage, which is parallel play. And when children are very young, they go from playing by themselves to parallel play where they're in the same room near a friend or sibling or cousin, and they're kind of playing on the same things. Like we're both playing cars. We're not playing cars together. I've got my cars. You've got your cars. But we're playing next to each other. And every once in a while we'll trade cars or whatever, but we're doing our own thing near each other because we kind of like each other and we like the camaraderie of being in the same room. But we haven't yet gotten to the level of truly playing together yet. And so I thought of that developmental stage. And then it got me thinking about the many, many interviews I've done for software developers over the years. And I've often asked people about collaborative coding. And at different times, I will use different words. Like sometimes they'll say, "tell me about experiences you have pair programming." And when I say, "tell me about experiences you have pair programming," if people have no experiences actually pair programming, they will often describe this kind of parallel play where they're each working on their own thing in a room, but they're kind of friendly and go to lunch together. And they'll always say something like, "yeah, we pair program every time somebody's working on something really hard. They'll just ask for help and we'll just jump in together on one computer and we'll work on it together." And that's their version of pair programming. But in reality, most of the time what they describe is this parallel coding.

[00:19:08] Allan Stewart: Yeah. And again, I think that this does break the ceiling of the independent work. I think you can get additional benefits. I think you get higher quality and better shared code understanding by taking this step. But yeah, there is still an aspect of that, right? Like you're saying with the parenting, I've definitely lived through some times where my daughters were in that parallel play step where I'm not good at playing Barbies, as it turns out. But as long as I occasionally say something for the Barbie and hold them up and wiggle them around so that they are moving or playing in the dollhouse, then that was good enough because that was a level of interaction that was expected. And I think that there's something maybe similar here with the parallel coding is that as long as you have those people who are there with you, there is an opportunity to have an interaction in a way that you couldn't before, and you've gained something, but it's maybe not the, the rich and deep interaction that, uh, that, that a parental unit might've been hoping for when they're told, "no, no, no, pretend they say this."

[00:20:35] Dave Adsit: Right. So, uh, to, to list a couple of those things that I think you get, one of them is is you get reduced lead time because you're working as a team on one feature or product, right? You're working in alignment with each other on delivering something. So that can reduce your lead time to getting it done. You also can get social pressure to follow rules. Even if you're just in the same room with somebody, if you've all agreed, "we are going to use this pattern." Well, when you get to code where that pattern applies, you are more likely to use that pattern or you're more likely to write your tests, either TDD or at least unit testing. You also get the opportunity for greater courage. If you need to do a refactoring and you know your coworkers are right there, and if something goes wrong, they're all working on the same feature with you. You can have greater courage, and you can even summon somebody over to help if it gets hard, right? You could actually do that pairing that we talk about when it gets hard. And so there's several reasons why parallel coding is a better form or a higher form of collaboration than strictly collaborating through the code. And it opens up the gateway to the next level, right? I've already talked about it. We've talked about it many times on the podcast. Next level up, the next step up in collaboration is pairing. Actually working together, two people, two, two developers, one computer, one problem, one card, one feature that you're building together as a unit, the kind of thing where at the end, you're like, "well, we both, who wrote the code? Who do I give credit for too? Well, we both wrote the code together. We both get credit equally."

[00:22:23] Allan Stewart: Right. This isn't the parallel version where we say, "Hey, we've broken this task up. You do some and I'll do some," but it's literally two people doing it together so we're both agreeing on the code, um, and the best way that I have seen this work, um, is to have two roles. One is the driver and the other is the navigator. The driver is the one with their hands on the keyboard and is actually doing the typing, but anybody who's been in code for a while ought to know that typing is not the bottleneck for coding. It's, it's thinking and, and figuring out what should be done. And so your other role is the navigator, and the navigator is, is the person who is directing the work for this period of time. So they are talking out the ideas, and there can be be some discussion back and forth, but to avoid, if you don't, if you don't establish these roles, what I've seen, um, when people try to do a kind of an ad hoc pair programming that they haven't, they haven't practiced the skill of pair programming, it's kind of just a fight over the keyboard. Um, or it's, "well, let me show you what I mean." And then now I take the keyboard and and write code for 20 minutes or, like, like I can't express myself without just typing,

[00:23:53] Dave Adsit: writing the code. Yeah.

[00:23:55] Allan Stewart: But the driver navigator concept works really well to, to give, to give structure to this scenario where yes, we do want to end up with one thing of code and we do want to create, create it together, but we can't both be typing at the same time, or not effectively.

[00:24:13] Dave Adsit: Right. One of the things I like about this is that those are not fixed roles and they shouldn't be fixed roles. They are, you don't decide and stand up at the beginning of the day, "I'm going to be the driver today and you're going to be the navigator" is like, no, this is a dynamic thing that changes throughout the day. And there are different strategies for that. One of my favorite is strong pairing, where basically the idea there is that the person who knows the system better doesn't do the typing. They communicate through the other person. They communicate into the code through the mind and hands of the other person. So if I've been working in this code base for a while, or I understand this feature really well, I went to the user interview, and so I know what we're trying to accomplish. I will tell you what we need to do, and then you execute it in code. And now I know we both understand it because I explained it sufficiently for you to write software code, you know, computer code that executes the functionality. And you have many opportunities to ask questions. And that can change. If we're working on a code base that we're both familiar with, that can go back and forth. Like, I know this part better, you know that part better, or maybe we both know it better really well, but I'm going to be the one who is guiding this part, and you're going to guide the next part. And so the knowledge of how the system should be flows from my mind, through my mouth, through your ears, through your hands into the code. And that way I know that we are increasing our total collective knowledge and understanding of this code base.

[00:25:50] Allan Stewart: Right. And it keeps everybody engaged. Both people have to be engaged for this to work. Because if the person doing the navigating isn't engaged, then no typing is happening either, because they're not communicating the idea of this is what we should do. Or if typing is happening, then it's just a solo programmer again. And you're not pairing. But if the driver's not doing it and the navigator is talking, well, then nothing gets done either. And so it facilitates a level of engagement that you wouldn't otherwise get.

[00:26:24] Dave Adsit: So this kind of strong pairing is really probably most appropriate for when we have a disparate level of knowledge of the code or the problem or the solution. And where one person is trying to guide the other one to executing on a solution. And so if we're talking about where we're more equal in knowledge, then probably another strategy would make more sense. Like one that I really like is ping pong, where I write a test that fails and you implement it. And then you write a test that fails and then I implement it. And then I write a test that fails and do some refactoring, or I do some refactoring and then write a test that fails. And then you implement it and then you read it, right. Do some refactoring and then do you write, it goes back and forth that way. And we are both putting our ideas in the code and we're guiding each other through tests. And this actually is a good strategy for improving our ability to write high quality unit tests. We don't typically do this as part of our daily work because we're trying to accomplish a goal together. But a thing I learned by going to code retreats is that you can be an evil pair and you can write any code, but what was intended that passes the test and then hand it back. Right. So we don't typically do that when we are working on our production code base and trying to finish a feature, but it's not a bad idea to do that occasionally intentionally and say, "Hey, write some good, write some better tests, and I will stop writing code that is wrong." So that, that can be a good way to think about, you know, the ping pong strategy for pairing

[00:28:13] Allan Stewart: collaboration and pairing. Yeah, and you can do that with a strong pairing concept still, right? Um, it's just you're switching your navigator role so often because you, you both are participating in that, as opposed to the disparity that existed in the other example where, "hey, I understand this and you're helping me to accomplish it, right?" It's just kind of two different modalities, but using the same mechanism of, well, somebody's got to tell you. And the other benefit that this brings to us that I think is really great is it helps us learn the terms for things. What is the difference between a class property and a field and a method? These things have names. And when we learn the names of them, it's a lot easier to communicate. And we say, "oh, yes, we are talking about the same thing." And now occasionally we'll come up with our own names for things. Like a lot of the people I've worked with for a lambda expression, we'll, we'll verbalize it as "goes to," because it's a, it's an arrow, you know, this thing goes to something else. And as long as you are consistent about what that means, then, then that's probably fine. But I think it's even more powerful as you learn, well, what are the, what are the actual terms so that you can say what it is that you want to accomplish? And you can move up in abstraction as you do that. It's like, if I'm pairing with you, I can just say, "Hey, I want you to inject a user repository," and you'll know exactly what it is that I want you to accomplish without me having to say anything else.

[00:30:01] Dave Adsit: You won't have to describe how constructor injection works and how fields work and how we store things on a field and any of that. Right. So that, that's a second, that's another strategy for swapping, typing, right? We want both, both members of a pair to be engaged in writing the code and writing the tests and being part of the system and feeling like they are accomplishing something. Um, one of the other strategies, I mean, you can do things like, you don't have to have a formal strategy. You just kind of do, go with the flow. Sometimes I'm typing, sometimes you're typing, and we're just talking as we code. That works sometimes, it works. That can work well depending on whether or not somebody is a keyboard hog, like I can be. But you can also just straight up use a timer. Pomodoro was really popular for a while in software development. That's, we're going to do, I'm going to type this Pomodoro and you're going to type the next one. So that means I have 15 minutes hands on keyboard. Then we take a five minute break and then you have 15 minutes hands on keyboard, whatever your Pomodoro length is. So that's another strategy that can work. I've seen that one less often in pair programming and more often in mob or ensemble programming, but it can work in pair programming as well. Yeah.

[00:31:16] Allan Stewart: Another one of the benefits here is that you can get more stuff done more quickly, which is counterintuitive because when you, when you look at it from kind of the, uh, a lay viewpoint, you'll look and you'll see, oh, well, there are two programmers sitting at the same computer working together, or they might be on different computers if you're doing pairing remotely, right? But nevertheless, you've got two people working on one thing. They're working on the same code. They could both be just typing away on different things and we get twice as much done, right? Well, no, not necessarily. There are a bunch of things that happen when we work together. We have better shared knowledge. We prevent each other from getting stuck so often. We have a higher agreement about what it is that is being done. The quality of the code is higher. In his Modern Software Engineering channel, David Farley cited the experience of a company that was able to get things done three times quicker, more features, three times more features in the same amount of sprint or whatever timeframe that they were measuring because they could be more effective, right? The two heads is better than one concept or the sum of the whole is the greater than the sum of the parts. Or the whole is greater than the sum of the parts. However that phrase goes, right? Like that truly applies here. And you're avoiding other kinds of problems that slow you down, like the necessity to switch gears and context switch for code reviews or dealing with merge conflicts and other problems that can readily occur if you're working independently.

[00:33:09] Dave Adsit: Well, and you've already said it. Typing is not the bottleneck. Thinking and understanding and problem solving are the bottleneck to software development. We spend 10 times as much time reading code and coming up with a solution as we do typing the code that is the solution. I mean, how many times have you been in something where you're working on it and you're working on it and you're taking hours to figure out what the solution is, and then you find, "oh, there's a bug right here in this line," and you end up changing 10 characters. And you, you know, it took you four hours to come up with which 10 characters to replace, but that's all it was.

[00:33:45] Allan Stewart: I mean, that happened to me just the other day. There was literally a one character change, and it made all the difference for this bug that was non-obvious. Yes, there you go.

[00:33:57] Dave Adsit: Pair programming is a very good strategy for collaboration. When I talk about collaboration, I often think of pair programming as the bare minimum for real collaboration and the things we talked about before, you know, using the code base as our collaboration tool or parallel coding as kind of precursors to real collaboration, two people working together on solving one problem. But we can go on from there. It can get bigger, it can get better. And so the next step up is to move into mob programming or ensemble programming, as it's often called now. And this is a whole team or a subset of a team, three or more people working together on one problem at one computer. Or if they're remote, like one person is the driver and the others are the navigator and participants, right? When I think about this, I think in the wild, I used to often see and still do see groups get together and call a war room. A war room is kind of, you know, you're having an incident, something's gone wrong. Your war room can be your ad hoc untrained model of mob programming. Why do we do it? Because it reduces the lead time from identifying a problem that's causing an incident in production to resolving that problem in production. And so, you know, not every war room runs the same, but often I've seen a huddle of people around one computer where they're each throwing out their ideas on how to solve it. "Oh, look at this. Look at this. Is it this problem? We released this. Should we roll it back? Oh, look over here. The drives are really hot or the The CPU is really high on this. Can we manually spin up additional nodes or pods?" So war rooms often run as kind of untrained, unintentional ensemble programming sessions. Another thing that I've seen often, more often probably 10 years ago or so, is hack days where everybody's like, "hey, we're going to, as kind of a weird thing, different than our normal way of working, we're going to try this thing where we get four people together or six people together, and they're all going to work on something together. And they're going to try to deliver something as quickly as possible, maybe in two days." And so you can take that same mindset, that same strategy, and you can bring it into your day-to-day work where you as a team are maximizing your, I don't want to say maximizing the velocity. That's not quite it. You are are minimizing your lead time. We have an idea. We have something we want to do. Let's minimize the lead time. Let's get this done as soon as we possibly can. Let's all work on it together. We're going to share a computer. We're going to keep the product manager really handy to answer every question that comes up. And we're going to get it done as quickly as possible because we're all working on it together.

[00:37:05] Allan Stewart: I think the key to go from that kind of untrained, like we don't really know what we're doing, but we're getting these benefits like where you would with a hack day or war room, is taking on the roles, right? Just like we talked about to make pair programming effective with the driver and navigator and using strong pairing. I think those principles really apply to doing effective ensemble programming. But now you've got additional people. And so So if you're learning and you're new to mob programming, then usually I just want one navigator and one driver and everybody else is kind of suggesting and they're communicating with the navigator, but it's what the navigator says that actually is the important thing, right? They might throw some suggestions or say, "hey, did you think about X?" But once you're comfortable with working in a mob, I've seen it work very effectively where you can have multiple people navigating and they just kind of naturally take turns as different ideas are suggested and say, oh yeah, that's a great idea. "Oh, can we do this?" And it just kind of flows. You do need some way of alternating roles, right? Just like with pair programming, and you may be a little bit more likely to use a timer if you're gonna do mob programming. But there are also other roles that can be taken up There is an interesting GitHub repository that's called the Mob Programming RPG that suggests a bunch of other ideas for things like the rear admiral or the researcher and the traffic cop, which are basically giving assigned responsibilities to people who are not currently the navigator or the driver, and giving them something specific to do to avoid the tendency of just kind of of drifting off as like, "oh, well, it's not me right now." And really, this is probably the biggest weakness I've seen with mob programming, is if you are not diligent, if you're not keeping yourself engaged, it's easy to slip off and kind of fall out of the mob.

[00:39:23] Dave Adsit: Yeah, we live in a world of digital distraction. And if you are remote mobbing, so much more so. So you are a computer programmer. You probably like computers and your computer is probably a very good tool for distracting you, right? So when you're in the mob, it is essential to stay in the mob, stay engaged.

[00:39:46] Allan Stewart: Although I have noticed that there is the ability for people, if they are maintaining regular connection with the mob, that they can step away and then come back and reintegrate very quickly. And the nice thing about this is that that can allow you to handle distractions. So there can be somebody who steps off. Sometimes I've heard of, this is the Batman role where they will go off and take care of a distraction. And, you know, somebody comes in and says, "Hey, we have a question about X," or there's a message on Slack that somebody's asking the team something that can be somebody dedicated to, "Oh, let me just handle that because I'm not the driver or the navigator right now," but I can very quickly come back up to speed with what we were doing because of the collective group thought process that occurs when you start working in a mob.

[00:40:44] Dave Adsit: That's right. Yeah. Somebody might be the communications officer for the mob, right? And keep all the Slack notifications away. You can also include non-programmers in a mob. Like I said, you want to have your product manager, maybe your designer really close. Maybe if you've got a product owner, if that's a role in your organization, somebody who is the executive sponsor or the person like somebody from your support or sales team who has actually been incremental or instrumental in requesting this feature and knows a lot about it and its uses. You know, having them nearby can be super valuable and they can be an active participant in the mob and they can be one of the suggestors or possibly even a navigator. We've thrown a non-programmer on the keyboard in some of our mobs and we get to practice talking about programming at a much, much lower level. They probably don't want more than a couple of rotations a day where they are the driver, but you don't get to say "X goes to" when you are talking about the lambda. You say, "okay, type an X. Now type a dash. Now type a greater than sign. No, trust me. Now type X dot." Right? You get to talk at a much, much lower level. And it's a lot, you get to be reminded of what it was like to learn programming and why it's a specialized skill that's hard for people to, you know, get used to or get good at.

[00:42:20] Allan Stewart: And again, just that flexibility is really nice because the non-programmer can join for a time, right? So I've had very, very good success with this with UX designers some, sometimes a UX designer might be shared across a couple teams. But even if not, if they can come and sit with the mob for a while because we're doing some user interface work, is much, much faster. The feedback loop tightens amazingly quickly when you can do that, and and they're, they're there and they're seeing the problem, right? Because sometimes that these issues come up where we've got the design of what it, what we want it to look like, how we want it to work, but reality gets in the way, or, or some technical issue. It's like, "oh, well, when we do this, it breaks the box model for this part of the page, and we can't rewrite this part of the page without rewriting this, you know, these other seven components." And if you've got your UX person sitting there and they're, they're understanding that, like, you're not just, you're not just BSing them because you don't like their design, but, like, you're actually struggling to make it come alive. Oftentimes they'll be like, "oh, well, we can make this tweak. Would that make it easier? Oh yeah, that's way easier. Okay, let's go. Let's do it." And everybody's happy, and you got it done really quickly. I also enjoy the flexibility of being able to step away. If I need to go use the restroom, things continue. If I have a meeting that I've been summoned to, or I need to take an early lunch or something, work continues to get done, even though I wasn't there. And when I come back, I can reintegrate with what is going on and observe what progress was made. And we move on.

[00:44:09] Dave Adsit: Well, and this is a really good way to share context across distributed groups. So you and I have a friend who we used to work with, who has long had an aspiration to have a 24 seven mob, or at least a 24, six and a half mob, right? The idea being that if you have a team that is geographically distributed around the world, the mob starts for each person at the start of day, their local time and continues until the end of day, their local time. But the mob itself never stops. And this can be a much better strategy than trying to have your team in the US and your team in India work on different things and then integrate at the end. The team in the US and the team in India and the team in the Eastern Europe just do continuous handoffs as people come on to the mob. And context continues because we're just still working on the same thing together. And after a few rotations, the people who just joined the mob know what the mob is doing and where the mob is going, and they've got a good understanding. And then you just, the people drift off as their day ends, and the mob continues, and the functionality continues. And instead of the next day coming in dreading what's been handed off incomplete without tests or whatever from your overseas team, you have something that you know was continuously worked on with the same standards and practices as your whatever, your US team, your Indian team, your whatever, wherever your remote teams are. You can have a mob that just continues to sustain. And I think he said he recently ran one for a while, but not the full 24-7. I mean, I think there are still weekends in there somewhere. But the 24-hour mob working on the same problem is the shortest possible lead time, while still maintaining working standards of we're not going to work more than eight or 10 hours. We're not going to try to have a death march. We're just going to continually sustain the same group. The same group. I guess that goes back to that philosophical question of, if you replace every plank of the ship, is it still the same ship? I think it is. In terms of a mob, I think it's still the same mob, even as people come and go.

[00:46:37] Allan Stewart: I love it. The mob of Theseus. The mob of Theseus. And then I think that the final thing to understand, if you're going to do this really well, Chris Lucian has a quote that I really like, "if you're not contributing or learning, join another mob." So as long as you're staying engaged, this can be a very effective way. It is basically a implementation of single piece flow, the principle from lean development. So it can be a very effective and I think fun way of working. Although it does require you to interact with code in a different way than a typical software developer is used to.

[00:47:25] Dave Adsit: So we've talked about increasing forms of collaboration as creating better results, and definitely in reducing lead time to high quality completed software or functionality. Right. But it's not all roses. There are some pitfalls to avoid, some challenges. Right. You, with the exception of the mob of Theseus, you pretty much have to be working synchronously, you know, same time zone, same overlapping work hours, in order for most of this collaboration to work.

[00:48:00] Allan Stewart: And even in the mob of Theseus, you still had to figure out how to keep at least two people, probably three people on the same thing at any given time.

[00:48:09] Dave Adsit: Yeah. At any given time during the 24 hour period, there's at least three people working.

[00:48:13] Allan Stewart: Yeah. Yeah. And there's also the misconception that working in parallel is always better than working together. That is something that is very rooted in our intuition, despite it being inaccurate. And that creates a perception that teams aren't really working hard. And so it's very important that if you're going to try some of these things that you have some buy-in and you look at the results of what's going on, not the perception of what's going on.

[00:48:46] Dave Adsit: Yeah. That can be a really, really challenging in organizations that are not familiar with lean concepts, that are not actually working towards goals, or that believe that typing is the bottleneck for developers. Another problem, and this goes back to the very first thing we talked about, which is sometimes it starts to feel like design by committee. And another term for that, another way of discussing that is, there's too many cooks in the kitchen. If you've got too many disparate ideas, you can start to see your progress towards a completed solution drop off as people argue about the minutia of their different perfect solutions. And so if you start to have too many cooks in the kitchen, that is one of the pitfalls of a highly collaborative style.

[00:49:39] Allan Stewart: Another is that this requires a level of social skill in addition to technical skill. And a lot of developers haven't built up this skill. There's interpersonal skill that you have to have to be able to talk back and forth with each other. You need the ability to talk about code and be able to communicate effectively what you mean with different terms that you're using. And honestly, it's easy for people to decide that they're going to hide or defer, especially at the mob level where you've got more than three people. If it's just a pair, it's harder to hide, but you can still defer and say, "oh, well, what do you think? What do you think?" And you're not really contributing. You're just kind of echoing. I mean, I can get a rubber duck that sits permanently, right? Or a ChatGPT.

[00:50:33] Dave Adsit: ChatGPT will always tell you you're right. "Right. Oh, absolutely. You're right. That is a fantastic idea. You can solve that impossible

[00:50:41] Allan Stewart: problem." So yeah, it requires us to actually engage and say, "Hey, if we're going to do this, we're not going to hide. We're going to actively participate." And as a quick aside, you know, what does pairing look like? If your pair is an AI, I thought it was really interesting that Neal Ford of ThoughtWorks fame on a podcast recently described it as being like 1.5 people. So it's still not quite to the level of pair programming.

[00:51:11] Dave Adsit: Yeah. And I think I agree with that. I think that one of the things that your human collaborator is going to do that an LLM just can't bring to the table at this point is curiosity. Your human collaborator is going to ask questions about why and how and are you sure, and your AI is most likely just going to agree with you and tell you what a great idea it was that you had. "You can solve distributed computing. CAP theorem doesn't apply here. You're absolutely right, Dave." So those are some of the things you need to watch out for. Some of the things that are kind of, you know, the pitfalls or the challenges of working in a highly collaborative style. But there are some benefits as well. We've talked about some of them. But let's just run through the list of the benefits that we've experienced. One is really tight feedback loops. If you and I are pairing, I am immediately getting feedback from you on my code. And I don't have to wait for a PR. I don't have to wait for a review. I don't have to wait for you to be available to read a Slack or anything. We're just, we're both here. We're both working on this. We're getting feedback and giving feedback continuously, and we're improving our solution in a way that we can never do asynchronously.

[00:52:29] Allan Stewart: Another benefit is we naturally get collective code ownership, meaning that both of us understand this code, right? So you have a built-in redundancy. If I am sick tomorrow, you still understand what it is that we were doing, and it can continue. And then you compare with somebody else and bring them up to speed, and now they have an understanding. And then if If I work with that third person the next day when I'm feeling better, we can connect and have a shared understanding of the code that doesn't really happen otherwise.

[00:53:03] Dave Adsit: Another benefit that I've seen on many teams is fewer and shorter meetings. Particularly if you are doing ensemble programming, the need for a daily standup is drastically reduced. For one thing, the whole team is working on one problem, one card. So how long does it take to report progress on one card? Very, very little time. And in fact, some of the teams that we've worked on, when the PM is an active participant in the mob, they just don't even bother with standups because everybody has context all day.

[00:53:38] Allan Stewart: They already know.

[00:53:39] Dave Adsit: They already know.

[00:53:40] Allan Stewart: Another benefit that I've experienced is consistent high quality. Because you are working together with other people, or at least one other person, they're bringing you along. Right? If they're kind of reinforcing the behaviors that you want to see, right? Like there's that peer pressure to do a good job. But also if I'm like, maybe I'm just having an off day and I'm not thinking very clearly, having a pair there to watch out for me is very nice. And they can help pick up the slack that I've got just because I'm having an off day. Or I've I've also encountered a lot of cases where I'll learn something from somebody that is like, "oh, I hadn't thought about doing it that way at all." But it's actually better and gives me better insight into a technology that I haven't been using or a way of developing that I wouldn't have tried on my own.

[00:54:35] Dave Adsit: Well, and another form of consistency that you get through pairing is consistency in your practices. You know, sometimes you don't know how to write this test, so you're just going to skip it. But your pair is going to sit there and look at you like, "are you really going to skip the test? Let me help you. Or let's figure it out together." Or maybe you're going to skip refactoring. Like, "yeah, this name isn't quite right, but I can't think of a better one. Or I don't want to take time to come up with a better one." And your pair is going to say, "hey, let's just refactor this. Like let's do red, green, refactor. You know, we've got a failing test. We've got a passing test, let's refactor the code and the tests." You can get more consistency around those practices that you've all agreed to. You had your architecture meeting and you all agreed, "we're going to do these practices." But then when the rubber meets the road and you're sitting there in front of the keyboard and you're by yourself and you don't quite know what the next step is, maybe you let some of those practices slip and you figure you'll catch up on them later. But if you're pairing or mobbing, you're not going to do that.

[00:55:34] Allan Stewart: I already mentioned the benefit that you can step away or you can trade out developers without having a big knowledge loss. And we mentioned speed. If you're watching outcomes and you're allowing for at least a little bit of time to train and understand that this is a different way of working, it can be much, much faster than working independently.

[00:56:00] Dave Adsit: And I would say, while I agree with that, I would be careful about using speed or velocity or productivity as your measure. I would look at lead time because people will always assume that if one person or if two people typing on one computer can get this done in three days, well, if they were each on separate computers, they could get it done in a day and a half. And the math doesn't work that way. But if you look at the lead time, you can say, "hey, the lead time goes down when more people work on the same problem." And so while those are mathematical inverses, velocity and lead time, right? Right. And you can take that, that DRT formula from algebra one, and you can arrange it. However works mathematically when it comes to the human psychology, the one that I like to focus on is how soon can we get there? How we can get there sooner if we work together. And do you want to get there sooner? Or do you want everybody to be busy typing? Which of these things do you value you most, delivering working software or keeping people busy? I like that. And so that kind of reminds me that this might actually be better for organizations than it is for individuals. We've talked about how sometimes the most productive thing you can do for your team is sit on your hands while we finish something. And that doesn't feel good to be the person sitting on their hands when work is being done.

[00:57:27] Allan Stewart: Yeah. Yeah. And I think about that. You're going to have to make a decision. What is most important to you or to your, to your company? If it's, "I want to enjoy the freedom of, I can just code and do whatever I want." Well, then collaboration might not, might not be the best way to have a fun time in programming, but if it yields a better result for the business, that might be worth it.

[00:57:54] Dave Adsit: I agree with that. We get to to play video games for fun. We get to program, which is usually very fun, but that's still our job. So we're going to work, and work is work, and work is not fun. We're going to work, and work is work. And sometimes work is not as fun as it could be if I could just do it by myself. Yeah. It's still pretty fun. And if you're even a little bit social, you can have a lot of fun in a collaborative work environment.

[00:58:20] Allan Stewart: Yeah. And I've found that this is true for introverts too. And it's because when you're really collaborating in code, this is more like talking shop and not discussing the weather. It's not small talk. It's real talk. Yeah, exactly. Just to kind of wrap up my thoughts about collaboration and collaborative coding, one of the ways that I've begun to think about it is the difference between bowling teams and soccer teams, you know, on a, on a bowling team, everybody performs individually and they can be on different lanes or they can be on the same lane taking turns, or, you know, they may not even have to communicate with each other at all. And they can, they can do this. So this is, this is a form of team, team sport, but it is very different from a soccer team. If the goalie isn't paying attention in the soccer team, you're going to have a big problem. If the person that you're trying to pass to just suddenly stops and isn't there, you're going to have a problem, because active collaboration is a different kind of interaction. It's a different type of teamwork, but it's also very powerful and allows you to get things done in a way that you couldn't with that bowling team style of everybody working completely independently.

[00:59:37] Dave Adsit: If you've ever watched little kids play, you will immediately notice that soccer is a terrible game that doesn't actually work because all the little kids are like little metal filings that are stuck like magnets to that ball. And so you might notice there's an analogy there. Little kids have not yet developed the skill of soccer. And so they do it wrong. And if you say, "therefore, soccer is not a good game, it's not a real game," then you have missed something valuable. And I would encourage you to think about that when you are getting ready to dismiss pair programming or mob programming as impossible or ineffective because you're not good at it, and you are playing magnet ball instead of playing soccer.

[01:00:24] Allan Stewart: Maybe go watch those videos of three professional soccer players versus 100 kids.

[01:00:30] Dave Adsit: Right. It can be a very powerful strategy if you take time to develop the skill or work with someone who can teach you the skill.