Slashdot Mirror
Mob Programming: When Is 5 Heads Really Better Than 1 (or 2)?
itwbennett writes: Proponents of Mob programming, an offshoot of Pair programming in which the whole team works together on the same computer, say that it increases both quality and productivity, but also acknowledge that the productivity gains might not be readily apparent. "If you measure by features or other classic development productivity metrics, Mobbing looks like it's achieving only 75 to 85 percent of individual or Pair output for, say, a team of six or seven working for a week," says Paul Massey, whose company Bluefruit Software is a heavy user of the Mob approach. So, where does the productivity come from? Matthew Dodkins, a software architect at Bluefruit says the biggest gains are in code merges. "In a day spent using traditional collaboration, you would have to first spend time agreeing on tasks, common goals, deciding who's doing what... and then going away to do that, write code, and come back and merge it, resolve problems," says Dodkins. By bringing everyone into the same room, "we try to merge frequently, and try to do almost continuous integration." Matt Schartman, whose company Appfolio also uses Mobbing and wrote about his experience, gave Mobbing high marks for producing a quality product, but didn't find that it improved productivity in any measurable way.
Golly! How do you suppose that having one person at a time writing code, with the rest of the team effectively doing simultaneous code review, magically produces "fewer features" but "better code quality" than having everybody writing code, then throwing it together and maybe doing a cursory bit of code review at the end?
Next, you'll be telling me that having one or two testers per developer produces better-quality software than spending all your money on developers so you can "get more features".
"We are all Eric"
"There used to be 11 of us"
The certainty of jail time + loss of job, associated with a mortgage does it for me.
I'm guessing it works for solving some sorts of problems fairly well. But there are some problems I've run into that require some silent contemplation over quite a bit of time to come up with a solution. I have a hard time envisioning that working with pair programming (which I've done only in very brief amounts) or with mob programming (never tried, probably like most). There are also some problems so technically difficult that I need maximum concentration to keep everything straight while implementing or debugging it. Having a group of programmers surrounding me seems distracting to that end.
I could see how it might help in some situations... you're essentially programming while having a constant design and review meeting, so I can see how the quality of code would improve. You're unlikely to simply accept a sub-par solution, because you've got a couple other programmers to readily suggest solutions you haven't thought of yet. The fact that it improves quality but not productivity should really come as no surprise, as you're essentially multiplying the brain-power focused on a single problem, but five programmers can't necessarily solve a problem five times faster.
An interesting concept. I don't think I'd want to *always* program that way (nor pair programming), but I could see it being helpful at times. At the moment, I either work on my own projects or as a remote contract programmer, so I'm largely in the position of *having* to solve everything myself, and it's often fairly difficult to not have immediate access to other programmers for advice or assistance.
Irony: Agile development has too much intertia to be abandoned now.
This seems like another "fad of the day" approach.
All these new "methods" strike me as coming either from 1) managers or "experts" with little to no actual experience at the keyboard writing actual code, or 2) university professors and theorists whose code is all written by slave labor in the form of grad students.
They don't. That's why nobody does pair programming in the real world. You might do a "hey can you look at this" and work together for 15-20 minutes once or twice a month, but that's about it.
I still have more fans than freaks. WTF is wrong with you people?
A manager went to the Master Programmer and showed him the requirements document for a new application. The manager asked the Master: "How long will it take to design this system if I assign five programmers to it?"
"It will take one year," said the Master promptly.
"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?"
The Master Programmer frowned. "In that case, it will take two years."
"And what if I assign a hundred programmers to it?"
The Master Programmer shrugged. "Then the design will never be completed," he said.
This is one of the 'hidden' secrets of pair programming........the quality of your partner matters a lot. With pair programming, suddenly interpersonal skills matter a lot more than they ever did with normal programming, because you literally have to work with someone on every line of code.
"First they came for the slanderers and i said nothing."
Seriously, hire a developer for six figures and give him a few hundred bucks in desk space that doesn't even have four cube walls?
I've wondered that. Beyond noise as a distraction, when they're that close, personal hygiene becomes a distraction.
Hard to concentrate when you can smell your neighbor didn't shower this week.
"First they came for the slanderers and i said nothing."
They call it Mob, I call it RAID:
Redundant Array of Incompetent Developers.
"First they came for the slanderers and i said nothing."
Different people do well in different environments. I've been where everyone had offices. It sucked. Complete lack of human interaction, very few work friendships, and a high bar to actual collaboration. I found it a depressing environment. I work in an open environment now. Once in a long while I'll have trouble concentrating due to noise. But that loss in productivity is absolutely crushed by the gains due to just being able to talk to people. And crushed by the increased productivity I have due to higher morale and more fun at work. I'd run away from any environment with offices.
I still have more fans than freaks. WTF is wrong with you people?
The article talks about how this makes them more effective as a team because they suffer less pain with integration and merge conflicts. This makes me think they are working with a very poorly organised code base, or as a team don't practice use of interfaces/contracts effectively. If they inherited a code base from someone else, then it may be largely unavoidable, but if it's always been their own code, then in my mind it's a bad smell.
I have been working on a project for 2 years with a team that is 7 developers which is in on time and the client just finished their final testing today with no significant bugs left outstanding. As a team, we were almost always able to each work independently on tasks due to early establishment of good patterns and architecture as well as regular design sessions for upcoming work by our two most senior team members. Each team member would typically push their SCM (Git) changes up to several times a day and merge conflicts were rare and practically always easy to solve. We even changed to better patterns 4 months into the project and due to good layout of our code, we could run the new patterns side by side with the old ones.
So how did we largely avoid stepping on each other's toes? Code was properly arranged so that areas of concern were appropriately isolated. When working on a front end use case, the only area of contention was typically registration of a module, after that all your code would be in its own independent area which no one else was working on. If it was a large use case with lots of screens, one developer spends 20 minutes stubbing out the code layout, commits, pushes to Git, then everyone else pulls and goes on their merry way. If use cases need to interact with each other, then one developer ensures the interface is correct, which may involve a 10 minute talk with a fellow developer, the interface is immediately updated and pushed into the repository and again each developer goes back along their merry way.
You may have noticed me mention that we push quickly into our repository, the article mentioned developers trying to merge a week of work and that terrifies me. If code is properly isolated, then your work can be incomplete, but not affect the existing working code, or other people's work in progress, so you should push *at least* once a day. If you need to alter an interface on your side for a colleague, but you were in the middle of something and weren't really in a position to push your code, then you: Git stash, update interface file, stub out implementation file if needed, push, then Git pop, you can carry on and so can your colleague. Additionally, our CI environment (Jenkins) is building and running tests on every commit, if someone pushes something that breaks the build the whole team is notified and it's fixed within 15 minutes.
Another comment has already mentioned that the quality of code would be higher with the team approach, but in my experience, as long as the code is reasonably efficient and more importantly, easily understandable to anyone else looking at it, improving quality beyond that in most circumstances adds little to no real value for our client. Since easy to understand code is mandatory, in the event it needs a bug fix, or in the rare case it needs to improved, perhaps for performance reasons, it's not especially hard for any developer in the team to do so.
Of course it will be different working on our code in 2 years time from now for ongoing improvements, but as we have been doing for the past two years any time we feel our process isn't working well, we will discuss it during our regular retrospectives and adjust our process to cope with the problem, could that process result in team programming like in the article? Possibly, but I highly doubt it.
From my experience single programming with quality co-workers that you can interact with is the way to go.
Once they started scrum - progress slammed to a halt at the last big company I worked at. I have no idea why they blame programmers for excel spreadsheet failures that were timelined by project managers.
If I was lazy, I would love to have one person at a keyboard and happily chirp with the rest of the crowd on how to process a variable. I don't understand how that actually saves money - anyone with spreadsheet skills, can you show me?
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
Getting rapped by buch of programmers is worst experience ever.
Yeah, it's pretty bad.
Indian programming shops suffer from the same issue that our own ones do: lack of quality control. The difference between a good and a bad programmer is a factor that runs into double digits, but that doesn't do you any good if you're unable to recognize, attract, nurture and reward talented people. Most firms in the western world fail miserably at this. Why should India be any different?
Another complication is introduced with outsourcing. Before, the manager was responsible for hiring and staffing teams, and appraising their employees. That was too troublesome, so development got outsourced. Now they complain that the Indian programmers don't understand their business. Well, sitting half a world away working for a different firm tends to do that. They also express disappointment in the fact that the Indian team is about as dysfunctional als their own old team, despite assurances from Indian management that they are a highly professional shop, CMM level 5 hundred, ITIL-trained, ISO over 9000, with all the right certificates. Must be that the Indians suck at programming, right? Or maybe it's due to the fact that you thought you hired 3 FTE worth of average programmers, but you didn't get 3 FTE, you got Gupta, Lakhsmi and Pradeep. Gupta was struggling a bit, but Lakshmi did well, however she quit and joined a firm that paid better money. Pradeep is brilliant but he got moved to a different team doing a difficult project for a high level client.
There are good Indian programmers out there, and I've worked with them plenty, but through the layers between myself and the remote teams I found it hard to find the good ones and even harder to retain them. That is another hard lesson about outsourcing: if you do it, you may think you're outsourcing responsiblity and buy with it the right to scream obscenities at lying vendors who underperform, but you have also largely lost the ability to control your team, who is in it, and who gets rewarded for good work. You now rely on the vendor to do that for you, but guess what: he may have different interests at heart.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Okay, I didn't actually mean just typing but the headline was too short to explain. We have at least one, maybe two people in our group who actually produce fairly decent solutions but who are just s...l...o...w at ad hoc work. For example we're in a meeting discussing something, I can whip out a query in a minute to answer and he'll have to take it back to his office after the meeting and work on it for ten minutes to find the same. He's slow at typing. He's poor at using auto-complete. He constantly needs to reference documentation and diagrams.
The thing is though, he produces solutions that are actually good and work well, unlike some of the others who either make weird designs causing grief down the road or buggy code leading to fire fighting. If I was asked as the manager who I'd like to let go, he wouldn't be near the top of my list. But if I had to sit there fiddling my thumbs while he worked, I'd probably be ready to quit in less than a week. I'm guessing in pair programming he'd hand me the keyboard, but in "mob" programming I'm sure there'd be some enforced round robin system so the one holding the keyboard isn't dominating.
Live today, because you never know what tomorrow brings