Is it better to have one book finished or two books halfway done? Some time ago, we ran into a similar problem at work. We were delivering just a few finished features and functions, while we had plenty of ones in progress. We could have dozens of new developing requests that were being developed in parallel and took quite a long time to finish. How to break this loop and improve effectiveness?
Stop starting, start finishing! That’s the key motto we started to follow ever since. The key metric for us has become the time it takes to resolve a client’s request and we have made almost everything subject to this metric. We figured it was better to focus on one task from start to finish without interruptions and downtime rather than trying to tackle two tasks simultaneously. That’s easy to say, but the reality is often more complicated.
Pull requests and reviews
Take, for example, the kind of reviews we used to do back then. After we had spent a week programming some new features for our lovely users, we submitted our code to another developer for the review. He obviously didn’t have time, because he was working on his own projects and that created first delays where we were just waiting for others. Finally, after a couple days of waiting, we get to the review, only to find out our beautiful code isn’t in line with his ideas and is asking for some modifications. Some of the modifications are implemented, some the original team doesn’t like, so we object against them. Since we have had soft-skills training, we know that developers usually use one level worse communication than would be ideal, so we decide to call the reviewing developer to sort things out. A fine idea, but this colleague has already left for a two-week holiday in Mauritius, which he made sure to recommend to us. Okay, so we go looking around the office and find another victim in the corner of the kitchen, and since he has nowhere to run, he promises to look at our code the next day. Three days later, we received an email saying that this is all wrong because half the code should not be there at all, since we already have the same code in a library that was created six months ago and which we obviously didn’t know about. But that doesn’t bother us too much, because we are already reading the email at the Prague airport on our way to Mauritius.
Starting with mob programming
So even though you spend just a couple of days programming something, it still takes a few weeks to get the code into production for users. How can one get rid of such downtimes for code reviews, and at the same time be sure that every line of code has been seen and reviewed by more than one developer? By having at least two people, preferably more, writing the code throughout the development process. So we started “mob programming”, in other words “group programming”. Back then it was still combined with covid and forced home office, so we jumped straight into “remote mob programming”.
This was done by several people forming a typical team of three or four, occupying one zoom room and working together on a single task. Really together and really working on one task – everyone is in the same zoom room all the time, one person is sharing the screen and writing the code, and the other three people even though are not programming themselves are still consulting and communicating with each other on how best to solve the task. After a while, the people switch roles and they all take turns sharing the screen. This goes on and on until the task the team is in charge of is completed.
It works
One of the main advantages is that the team that is “mobbing” doesn’t have to give their code to other people to review, because enough people have already seen it. This eliminates the eternal ping-pong, where people argue about something in the comments for days and it’s still not good enough. It also eliminates the other frequent slowdown when someone goes on vacation and leaves behind work to be done. In groups of four, there is usually always at least someone who stays and can continue with the work. Thus, no task is ever stopped, someone is always working on it. There is no waiting for reviews, no waiting for vacationists. If there is some downtime, it’s usually caused by waiting for a third party, maybe for a client to reply, and there’s not much you can do about that. So the whole development process is much smoother and the team delivers individual tasks faster than an individual who has to wait for someone and who is always being held up by something.
A pleasant side effect is that we naturally have fewer tasks in progress. When we had 20 developers all working on something on their own, we were working on 20 tasks in parallel and we had big problems organizing and coordinating it. But if we split 20 programmers into five groups of four people, we’re only doing five concurrent tasks at a time. Suddenly it’s orders of magnitude easier to manage.
Sharing is caring
Group programming is also great for sharing knowledge of all kinds. From little things like noticing that a colleague is using a keyboard shortcut in the editor that you didn’t know, to sharing domain knowledge. Training newcomers also works great, we have really good experience that rather than throwing a newcomer in the water and letting them swim in the code alone, it’s much better if they are part of a group – they pick up the company principles and programming style faster. And he starts to be useful much sooner than when he spends a couple days alone exploring code that is unfamiliar to him.
If you have a favorite style of programming, you can easily infect other team members with your enthusiasm for eg. functional programming. Or you can be shown that inheritance really isn’t the best way to share code, and that inheritance is for houses, not classes.
In group programming, this leads to softening hard edges of coding, leading to nicer code overall. You won’t get away with super-advanced and hyper-complex one-liners, because there will always be someone right in the group who doesn’t understand such notation. Even while you’re writing, you have to write the code in a way that the remaining team members can understand it, any ambiguity has to be cleared up now, not in two weeks at review.
Remember the other day when you were programming and you got stuck on something simply stupid? On some silly detail that you didn’t get, you burned three hours of time on it, and finally a colleague came to you and told you in half a minute that you were missing a semicolon? In group programming, you have three colleagues available like that. Non-stop.
Decision making
Any decisions that are made are discussed in a group of four. Of course, not even a group of four people will always make the right decision. A larger number of people does not automatically mean that the decision is correct. But the chances of finding the right solution are greatly increased. Indeed, it’s rare that a group would turn in a problem that was somehow solved completely wrong. There may be problems in the details, but it doesn’t happen that they turn in a solution that is fundamentally wrong.
If a group submits a solution, it is usually more confident and more committed to it. It is also far less stressful than when an individual has to make the decision.
Four times lower performance?
When we first tried group programming, we were afraid that the overall performance of the company would drop. After all, if four people will do what one person can do alone, that must mean we get four times less done, right?
Unfortunately, we have no hard data to confirm or refute this assumption. So, we have to go with our subjective feeling telling us that there is no loss of performance. We are seeing the obvious benefits in situations when there is a problem with a system, and four people who programmed that exact thing are immediately available and able to intervene quickly, so there are no moments like “we have a problem in production and the person who developed it is in Mauritius”. The whole development process is much calmer and less stressful because you know you’re not on your own. That you can just take a vacation in peace and there will still be someone at work to finish the work in progress or fix a bug in production for you. At the same time we see that in departments (with no mob teams) where there is no such substitutability applied, it leads to real problems like “we have a problem with this script that only our ex-colleague who left the company a month ago understands”.
In the general balance, we believe that the overall performance of the company has not decreased, but rather increased, thanks to benefits such as virtually perfect substitutability and higher code quality.
What caused problems?
Nothing is perfect. So what have we had problems with?
- Technical problems. When we do remote-mob-programming, there is of course a problem with sound, and overall remote-mob-programming is sometimes like summoning ghosts (“someone wants to join us”, “Elizabeth, are you there?”, “we can’t hear you”, “can you hear us?”)
- While knowledge sharing works well between members of the same group, sharing across groups is no longer assured. The solution is probably to rotate group members more often than we do now.
- Some people complain about not having that “flow” feeling, where you’re engrossed in the task you’re doing and just churning out thousands of lines of quality object code.
- A lot of people are bothered by not being able to listen to Cradle of Filth or other of their favorite bands.
- It’s a big problem in offices because it’s like a call center. You go in there, everybody’s wearing headphones, and you kind of feel like you’re not even in the office.
- Of course, every person is different and not everyone can handle being on call with three other people all day and communicating with them in a meaningful way all the time. It’s not like working manually all day, but still, after a full day of “mobbing”, a person can be very tired and mentally drained. In this case it is good to take a break from mobbing at least for a while.
Summary
Overall, our experience with (remote) mob programming is very positive and gradually most of the programmers in the company have switched to this technique. It’s something that we think is helping our development and something we intend to continue to do. Recommended by 1000 of the 1010 programmers at Stroeer Labs.There are also academic papers on mob programming, you can read this one for example: Mob Programming: From Avant-Garde Experimentation to Established Practice