A lot of the time here at GDS, we think the best way to solve something tricky is to share the problem. Often, it’s not a case of ‘too many cooks spoil the broth’, it’s a chance for us to get as many brains as possible thinking about the same thing. So actually, it’s like ‘a problem shared is a problem…’ well, it’s a smaller challenge for each person.
My name’s Paul and I’m a developer on the Digital Marketplace. Recently, our team of developers has been trying to solve a problem using mob programming. The development team on Verify has been experimenting with mob programming for a while, but this was something new for us. The idea is that “the whole team works on the same thing, at the same time, in the same space, at the same computer,” says Woody Zuill, the self-proclaimed father of mob programming.
Testing shouldn’t be testing
As with all GDS services, on the Digital Marketplace we constantly test different scenarios a user might find themselves in. We do it so we can be confident that everything works as we’d expect it to, so we can avoid broken user journeys like dead ends or user data not saving properly. There’s nothing more infuriating than completing an online form, clicking through to the next part and having everything you’ve filled in disappear.
In April, we were working towards putting Digital Outcomes and Specialists live (a piece of work we’d been developing for months). During this period of heavy testing, we realised that the code we’d written to test whether things were working as they should be, had become unwieldy and frustrating for our developers to maintain.
Because we’d already spent months writing the code to build the application, it was tempting to write the test code super quickly, and I think that’s what we’d been doing here. One of us would write some code to test a part of the user journey, and then when the next person came to write more, they weren’t always sure what the last person had done or what the next person would need to do. So, individual developers were making small changes without agreeing on common ways of doing things, and the code got more confusing as it grew.
Ready, steady, mob
As Woody suggests, we each took on different roles: one person typed and another led the session. While this was happening, the rest of the mob gave their input as and when it was needed. The main point of a session is that “for an idea to go from someone’s head into the computer, it must go through someone else’s hands,” says programming expert Llewellyn Falco.
The whole thing felt super collaborative because everyone was engaged in solving the same problem. Every 5-8 minutes, we swapped roles, being careful not to shove someone into a role they weren’t keen to take on.
We weren’t planning to mob forever, but by starting to rewrite the test code as a group, individual developers returning to the project later would be aware of its history and understand its design.
Could we fix it? Yes, we could
Rewriting the code seemed like a really slow process at the beginning. However, when we became more familiar with the process and settled on a direction, we gained momentum as we went. Together, we built up a collection of code that we all understood and agreed with.
Mobbing: another form of collaboration
We’re a collaborative bunch at GDS. Whenever developers work on things individually, someone else reviews our code. We also do a lot of pair programming (2 developers working side by side to fix a problem together), and we do group ‘story kickoffs’ where various team members talk about the approach to a piece of work before an individual developer works on it. Now the Digital Marketplace development team have also used mob programming successfully.
Each of these types of collaboration are suited to different kinds of problems. Since our particular problem stemmed from the team not having a shared understanding of the project when it began, using a collaborative method that involved the entire team from the start turned out to be a great approach.
Follow Paul on Twitter, and don't forget to sign up for email alerts.
5 comments
Comment by William posted on
Do you use this approach more widely or is it restricted to test code? It seems from what you say that it circumvents the need to document the code or the process and tries to do without a knowledgable team leader. Sure, afterwards some people might have a better understanding of the code as a whole, but newcomers who arrive after the (mob) event have only the code or asking questions to help them, with no documents available; once all of the mob (or those who really took part as opposed to freeriding) are gone, there is just the code. Furthermore, it might be argued that the test framework should be written *before* the application code, not afterwards.
This idea might work for a few people but it is very particular to extrovert workers. Those who are not vocal or whose thought processes are not dynamic (for example they like to think about a problem in a quiet space) will be left floundering with this approach.
Comment by Paul Craig posted on
Hi William,
Thanks for reading the post and sending in your thoughts! You’ve made a few different observations (all good ones!), so I’m going to try to address each of them.
We use all our ways of coding at different points. We’ve done mob programming more recently on some core application code where we felt it would be good to spread the knowledge around the team (see: https://github.com/alphagov/digitalmarketplace-api/pull/444/commits), so it’s really more about the context around the problem we’re solving than which project we’re working on.
I take your point about documentation, but I think that it’s possible to write appropriate documentation for code written by a mob in the same way as it’s possible to have no documentation for code written by an individual. Whether or not we’re mob programming, we always try to leave helpful documentation / commit messages (style guide here: https://github.com/alphagov/styleguides/blob/master/git.md).
Secondly, just as a point on documentation in general, the agile software manifesto privileges “working software over comprehensive documentation” (http://agilemanifesto.org/), and our experience has been that mob programming is good at getting us working software.
Finally, you’re right to be concerned about introverts, but I’d just like to be clear that most of the time we’re not mob programming: the post tells about a particular context where mob programming was a good fit but there are still many cases well-suited to working on code individually, and, for us, this is certainly the norm.
To address your point more directly — that mob programming might be difficult for introverts — I would disagree that this is necessarily the outcome, although it definitely *is* a concern.
As a team, it’s important to try to keep everyone involved who wants to be (even if they’d prefer not to type) and make an effort to be respectful and kind to each other. So we do our best to get everyone's viewpoint when we do mob programming, but we always treat it as an opt-in method rather than obligating developers to be there.
Comment by William posted on
Hi Paul, I didn't realise the mob was voluntary, but that makes sense. As an relative introvert myself, all I'd want to do would be type.
It did occur to me that this method must play havoc with project planning - if a job that one programmer can do is allocated a man-day and that balloons to 5 or more man days. Maybe the mob is built in to the plan; the same must need to be done for pair-programming - unless you find that things get written faster.
Comment by Stanislas RENAN posted on
Hi.
This mob programming very looks like an opportunity to share a lot with colleagues, including practise and not just ideas : why not give it a try?
Comment by Paul Craig posted on
Hi again Will,
Yes, this is the common criticism that I’ve heard about mob programming: that 5 developers doing what 1 developer traditionally does will accomplish one fifth of the work.
Woody maintains that mob programming saves more time by cutting out inefficiencies such as:
- code rewriting
- code reviewing
- other people having to learn code that they didn’t write
and other various small problems that come from not having a wide enough context of the project as a whole.
I don’t think we’ve proved whether or not mob programming is more efficient in every case, but it does seem to us to have been particularly useful for very gnarly problems.
I would recommend what Stanislas has suggested: just give it a try 🙂