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 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:37] 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 is doing things on their own. Right. 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 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. 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. How are we going to collaborate? How are we going to work together on this? Yeah.

[00:03:28] Allan Stewart: And ultimately that's what collaboration is about. How can you have more than one person working on a thing? And if you've got, if you have a group already like a company, well, then you already have multiple people trying to work together to make this, the company successful. And so you, you need some level of collaboration. Um, 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. Uh, 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. 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? They say, uh, a camel is a racehorse designed by a committee. So good for very, very long races across the desert. Right? So everybody, if, if you are listening, if you, 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 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, you know, 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 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. Uh, 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. Um, 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. Uh, yeah. So, um, you know, anything from, you know, how you do your team meetings, how you work with your product manager, how you interact across teams in a company. Uh, 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. Uh, 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, 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, it has to be the lowest form of collaborating on a software project. 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, at a, at a verbal level. You've got your standup 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 going to, you're not going to understand it. You're not going to 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 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, 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 work. Yeah.

[00:09:24] Dave Adsit: Yeah. You end up seeing a lot of standups that look like each person doing a status report 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 well. 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 on this team, 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 levels of 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 feedback. They're 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 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 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, it's a good thing. But at that point, you start, 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 the code. 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 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 gatekeepers. And then you've got 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, you know, 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 is to build a system. And 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 in the same room together. That might be a virtual Zoom room or, you know, screen share of some kind. 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 rather than waiting for an 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, yeah, 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 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 on the same thing. And so, if you can do a just in time code review, which is nice, it's, you know, it's more expedient than a pull request based code review. 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 area.

[00:17:16] Dave Adsit: Yeah. So when you first proposed parallel coding as the parent of young children, 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, you know, 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 other side. And I think that's where I started to think about the many, many interviews I've done for software developers over the years. And I've often asked people about collaborative coding. And, you know, 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 friends. They're friendly and go to lunch together. And they'll always say something like, yeah, we pair program every time somebody is 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 board. I'm not good at playing the 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 rich and deep interaction that a parental unit might have been hoping for when they're told. No, no, no. Pretend they say this.

[00:20:35] Dave Adsit: Right. So to list a couple of those. I think that there's a couple of those things that I think you get. One of them 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. Each of these is different. Each of these is different. Each of these is different. Each of these is different. Each of these is different. Each of these is different. Each of these is different. Each of these is different. Each of these is different. Each of these is different. Each of these is different. that pairing that we talk about that 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 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 to? 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. And the best way that I have seen this work 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 thinking and figuring out what should be done. And so your other role is the navigator and the navigator is the person who is directing the work for this period of time. So they are talking out the ideas and there can be some discussion back and forth, but to avoid, if you don't establish these roles, what I've When people try to do a kind of an ad hoc pair programming that they haven't practiced the skill of pair programming, it's kind of just a fight over the keyboard. Or it's, well, let me show you what I mean. And then now I take the keyboard and write code for 20 minutes or like, I can't express myself without just typing.

[00:23:53] Dave Adsit: Writing the code.

[00:23:54] Allan Stewart: Yeah. But the driver navigator concept works really well to give us a sense of what's going on. Just to give structure to this scenario where yes, we do wanna end up with one thing of code and we do want to create it together, but we can't both be typing at the same time. 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 gonna be the driver today and you're gonna be the navigator is like, no, this is a dynamic thing that changes throughout the day. And there are different strategies around it. Each of 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, 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. I know this part better, you know that part better, or maybe we both know it 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. Right. And it keeps everybody engaged.

[00:25:52] Allan Stewart: 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 the, you know, then it's just a solo programmer again. Yep. And you're not pairing. Or, 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. So this kind of strong pairing is really

[00:26:27] Dave Adsit: 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 write it, right, do some refactoring, and then do, right, 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. I mean, 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 can be a good way to think about, you know, the ping pong strategy for pairing, collaboration and pairing.

[00:28:15] Allan Stewart: Yeah. And you can do that with a strong pairing concept still, right? 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, 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, between a class property and a field and a method? These, 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 the, 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, 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, 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're accomplishing something. One of the other strategies, 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 know, you can also just straight up use a timer. Pomodoro was really popular for a while in software development. That's, you know, 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. Yeah. 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.

[00:31:15] Allan Stewart: Yeah. 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, 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, but there, 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'd 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, 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 do a lot of work. And he said, well, we're able to get things done three times quicker, more features, three times more features in the same amount of sprint or, or whatever, a timeframe that they were measuring because they could be more effective, right? The, 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 the greater than the sum of the parts. However that phrase goes, right? Like that, that truly applies here. And you're avoiding other kinds of problems that slow you down.

[00:33:19] Dave Adsit: 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, that happened to me just the other, the other day, there was literally a one character change and it made all the difference for this bug that was non-obvious.

[00:33:56] Dave Adsit: There you go. Pair programming is a very good strategy for collaboration. It's, when I talk about collaboration, I often think of pair programming as the bare minimum for, for real collaboration. And the things we talked about before, you know, using the code base as our collaborative, collaboration tool or pair parallel coding as kind of precursors to real collaboration, two people working together on solving one problem, but we can go on from there. We, it can get bigger, it can get better. And so the next step up is to move into mob programming or ensemble programming, which 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, they're like one person is the driver and the others are the navigator and participants, right? This is what I, 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. Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing Each of these groups is designing back oh look over look over here the drives are really hot or 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 yeah another thing that i've seen often i more often probably 10 years ago or so is hack days where everybody's like hey we're gonna as kind of a weird thing different than our normal way of working we're gonna try this thing where we get four people together or six people together and they're all gonna work on something together and they're gonna 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 philosophy that's not quite it you are minimizing your lead time we have us 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 gonna share a computer we're gonna keep the product manager really handy to answer every question that comes up and we're gonna get it done as quickly as possible because

[00:37:04] Allan Stewart: we're all working on it together i think the key to to go from that kind of untrained like we don't have any designing principles to designing designing designing designing designing designing designing want one navigator and one driver and everybody else is kind of suggesting and they're 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 you know 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 you just it just kind of flows you you do need some way of alternating roles right just like with prepare programming and you may be a little bit more likely to use a timer if you're going to do mob programming but there are also other roles that that can be taken up there is a 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 something specific to do to avoid the tendency of just kind of drifting off as like oh well it's not me right now it's not and and really this is probably the the biggest weakness i've seen with mob programming is that you can't just mob programming is if if you are not diligent if you are not keeping yourself engaged it's easy to slip off and kind of fall out of the mob yeah we we live in a world of digital distraction and if

[00:39:27] Dave Adsit: you are remote mobbing so much more 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 although i have noticed that there is the ability

[00:39:49] Allan Stewart: 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 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 there can be somebody dedicated to oh let me just handle that because i'm not the driver 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 that occurs when you start working

[00:40:43] Dave Adsit: in a mob that's right yeah somebody might be the communications officer for the mob right and keep all the slack notifications away um 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 actually been increment 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 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 uh x goes to when you are talking about the lambda you say okay uh 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 yeah or get good at and again just that flexibility is really nice because

[00:42:24] Allan Stewart: the the non-programmer can join for a time right so i've had very very good success with this with ux designers uh some sometimes a ux designer might be um shared across a couple teams but even if not if they can come and sit with the mob for a while they can do it they can do it they can do it in 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 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 it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box model it breaks the box 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-7 mob, or at least a 24-6.5 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. You know, the team in the US and the team in India and the team in, you know, 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, you know, a few rotations, the people who just... Just join 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... 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 with while still maintaining... You know... 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. 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 an 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. 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 and 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. Yeah. 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... It's easy 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 chat GPT.

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

[00:50:41] Allan Stewart: 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, what does pairing look like if your pair is an AI? I thought it was really interesting that Neil Ford of ThoughtWorks fame on a podcast recently described it as being like 1.5 people. So it's still not quite... It's 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 distributing. You can solve 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. I'm 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 get we naturally get collective code ownership, meaning that both of us understand this code. Right. So you have a. Build. 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 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 stand up is drastically reduced. For one thing, the whole 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 stand ups because everybody has context all day.

[00:53:38] Allan Stewart: All right. 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. 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 I'm not thinking very clearly. Having a pair there to watch out for. for me, it's 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 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

[00:54:33] Dave Adsit: I wouldn't have tried on my own. Well, and another form of consistency that you get through pairing is consistency in your practices. 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. And then you're going to sit there and 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 know, 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

[00:55:34] Allan Stewart: to do that. Yeah. I already mentioned the benefit that you can, you can do that. Yeah. 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. And I would say I, while I agree

[00:56:03] Dave Adsit: 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 this on one computer couldn't 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? 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 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 it. 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

[00:57:50] Dave Adsit: result for the business, that might be worth it. I agree with that. We get 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 it's 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

[00:58:19] Allan Stewart: environment. 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, it's not small talk. It's real talk. Yeah, exactly. Just to kind of wrap up my thoughts about collaboration, collaborative coding. One of the ways that I've begun to think about it is the difference between bowling teams and soccer teams 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. 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:38] 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

[01:00:24] Allan Stewart: soccer. And maybe go watch those videos of three professional soccer players versus a hundred 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. Let's go.