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"
I'm old school and write my own code, although it may be reviewed by others later.
A question: with either pair programming or mob programming, how do you keep from punching each other in the fucking face?
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.
Is this THE Matthew Dodkins? The Matthew Dodkins who runs the popular The Agile Dream blog, read by millions of readers around the world?
5 H1B's are better then 1 avg coder and cheaper but 5 avg ones can blow them away but that costs to much so we get poor work overall vs say a 1 good coder.
...don't turn this into a red-tape process.
It was bad enough when we needed 3 peer reviews on a log statement, now we need 5 programmers watching me type it??
Has code become so complex that one brain can't handle one statement? It's time for refactoring...
==UserScript== @name Nuke anonymous cowards
http://pastebin.com/7tsPe2X6
Had it with anon children. Sorry to those of you who occasionally post something of value without an account.
I'm sure there's a setting to control this in user options that's dead obvious, but I couldn't be arsed to look since the layout for simple checkboxes is hideously mangled. Also, I don't github/etc, and couldn't possibly care any less about "correct" JavaScript, so YMMV, don't expect me to reply with a how-to, etc. Enjoy!
... and we know how well those usually turned out.
Seriously, I'm still waiting from a company that realizes having private offices plus collaborative spaces (you know, a old school office) is the best way to go.
You need quiet to concentrate on a tricky problem. You have it. You need to get together as a team and work on something, you have it too. You have rooms with actual doors, you train people to use a proper conversational (not cell phone loud) tone and boom, productivity. Not chaos that mimics the appearance of creative work, but actual work.
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? That makes all the sense in the world, right. Argh.
Yeah, not a good idea. Sure if all the team members are mediocre or noobs then it may work but if you're dealing with some alpha over-caffeinated coders then it'll invariably lead to open arguments and people tearing off in a huff. Pair programming does work when the pair collaborates and gets along, i.e., have compatible ways of communicating both verbally and non-verbally. Taking that to a higher extreme usually results in chaos.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
I'm sorry that your imaginary bearded sky fairy didn't smite down those horrible judges for granting people equal rights. That's the thing with believing in imaginary sky fairies, they really don't do anything. Now... if you want to talk about the Great Noodley One, the Flying Spaghetti Monster, FSM gets sh1t done, for reals...
oh, I'm sure companies will be all over hiring 11 people for 1 job... So long as they're all willing to split the pay and bennies 11 ways.
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.
If you can't quantify something that should be readily quantifiable, then it's probably not there - no matter how much some PHB might wish it to be true.
With five people all interrupting each other and all trying to get their ideas heard, it likely means none of them are putting anything past a cursory amount of thought into the work. I can easily believe a group like this would actually be less productive than a single person coding alone.
#DeleteChrome
Some people are just naturally good at talking through what they are doing, though not necessarily (rarely, in my experience) the best, or close to the best, in actually getting the work done. They can actually be more productive when they are talking 1/4 to 1/2 the time. And of course, there is generally a lot of time for hip-techie talk, references to sci-fi movies and video games, etc.
The problem is that these folks also are good at grabbing management's attention and getting the lion's share of the credit, so the quieter folk actually doing the work will voluntarily move on to different projects or companies.
to summon a true master to do it much better than 5 mediocre programmers ever could, no matter what fad they used.
Hah, nice shout-out to Pomona, but Google Maps says that bar is in St. Louis.
Nice.
Here is a quick and dirty script I made to fix the "XX comments" Slashdot moved to out of the way balloons.
http://pastebin.com/1xUuuvtN
There's a problem with mobs: they gang up and lynch anyone who isn't part of the mob.
This doesn't happen just in westerns. It's been happening since the dawn of time, because it's a natural property of crowds: the least able thinkers are the ones most likely to be swayed by group-think. And one of the strongest group-think arguments is "Outsider, danger to group, kill it", which is a very effective survival M.O. for life below a certain threshold of intelligence. The combination of these two aspects of mob behaviour is predictable.
That makes TFS and TFA a bit of an exercise in wishful thinking. Development by mobs could (in theory) work well, but only in the very unlikely situation that the mob has a statistically improbable makeup in which independent thinkers are dominant and are also well informed and technically experienced. Unfortunately that scenario lies in "pigs will fly" and "hell freezes over" territory.
The perfect number in team programming is two people of similar experience, because then they can't gang up and form a lynch party. If they don't immediately agree then it creates a stalemate which can be broken only by rational explanation / defence or by terminating the pairing. It's an ideal situation, yet not too hard to arrange.
Mobs don't really have a place in intellectual endeavours, and programming is one of those.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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.
However, I practice a different form.
1. All programming, compiling, testing, and debugging happens on one system.
2. Everyone logs into that system (I remain local at that system) and we all start up a voice conference.
3. Everyone is able to write up code, sling it straight to me where I can immediately compile and test, and everyone gets to see the results and hear my experiences with the software as it runs.
I'm currently working on a little 2D version of SecondLife. Pair programming sucks. Mob moved us from code updates every week and shit progress to multiple updates per day and much much better progress.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
"... and Nancy, who we'd been working with for several years, suggested Mob Programming as one way to mature technical leads faster"
If you're a skilled architect with 15-20+ years experience, there's nothing to see here. Unless you need to grow new ones.
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
Did you mob program that one? If not it's not really on topic...
Looks like they put a government construction worker in charge of a programming team.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
If your like-minded gang of guys are out at a bar and come up with a great idea, this method is great for banging out the initial prototype on the one laptop that someone happens to have with them.
... but then its not called Mob Programming, but gang banging.
I imagine the junior programmer telling: "you have spent so much time trying to fix that bug.... so let me make you an offer you can't refuse".
There was an episode of Star Trek TNG where technicians from a race of cybernetically linked pairs were brought aboard the Enterprise for upgrade work. They communicated in binary and hijacked the ship.
I am patenting 24 people writing code simulaneously!
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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!
I've seen that, in college we worked on teams. Typically we split work, a pair does the programming a pair does number crunching and graphs, the usual freeloader brought pizza and beer, or was simply funny and friendly. But there were other teams doing exactly that, they usually were really stupid programmers sitting all together just helping each other do/undo the crap each other did. It kind of worked for them as they managed to deliver more or less decent homeworks.
I can understand pairs doing programming, but in my experience, three or more is just a sign they are too stupid and should do other things instead of programming.
Pair (extreme) programming was fun: one guy does 90% of the work, two take 50% credit each. Mob programming promises to be even more fun.
This is mob programming. If programmers write too many bugs, they get whacked.
Not sure if I would agree with the argument in question. http://www.dailymotion.com/vid...
When people are grouped into a small team with a simple hierarchy then interpersonal problems start to dissappear and the team effort becomes more important. In addition the team itself gains a group experience that grows and keeps growing if the team spirit stays alive even if one member changes once in awhile. Unfortunately this would require the right software, ide, shared screens etc... and at least a couple of years to grow. It should be more like bridge programming (like the bridge of a Navy ship). The momentum of a team can eventually be more than the sum of the parts if fed properly. I would even say that a tester and documenter (and whatever other non coder is required ) could take part and to put it even further perhaps each member would have a person or a smaller team working for them. Yeah if I had nine zeros to spare I would definitely try to grow something like this.
Really. Did they do a controlled study? How did they factor in the complexity of the problem domain, the experience of their developers, the efficiency of their tools etc.? Or is this just another buzz word compliant"'it worked for me marketing gimmick? Does it scale based on project and team size? What about global projects where the team may be in Europe, N. America, and Asia? How did they control for those factors?
Sorry, it sounds like crap to me.
putting the 'B' in LGBTQ+
Pair programming is a crap idea that never works. The better programmer just gets held back and frustrated with the other programmers incompetence, and the worse programmer just stays out of their depth. What you can only ever get is a mediocre piece of work at best since the better programmer usually has to compromise for the sake of the worse programmer.
So I guess the idea is to make the job comfortable to people who need lots of social interaction in order to be able to work? Generally like women? ... And to fuck people who like clear structure and who are better when working alone? Generally like men?
Getting rapped by buch of programmers is worst experience ever.
Yeah, it's pretty bad.
This is wishful thinking from the H1B overlords... "Hey we'll cram 50 H1B workers in a MOB ROOM and BOOM! Profits!
Well, it is on topic, because it stands as counterpoint to mob programming.
there's more players for the blame game and more heads to roll.
... which was probably what caused the problem in the first place.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Mob programming finally gives managers what they have craved for: action. With a single programmer quietly typing ahead you never quite know what's going on. The guy might be typing private emails or chat with his favorite secretary instead of writing code. So managers resort to all sorts of tricks to get some informaion out of this guy, like measuring lines of code or issues completed, none of which is a direct meauarement of productivity. Seeing 5 people in action, all babbling seemingly smart stuff, like semicolon! Nono, refactor that! hey guys, we need another jar on javapath! This must make the manager proud, gee see how all these smart people get stuff dobe, and I am the one who hired them!
Gee, what a big pile of BS.
We do pair programming for larger projects without many explicit specs. These projects require you to 'think up' use cases and requirements on the fly to ensure that your code is sufficient, complete and valid. For instance we created a replacement for a parser of complex documents that had to get classified. We had a coder with strong domain knowledge and a strong coder. Not sure what to do when n > 2.
nosig today
*Tadum* *Crash* *Thud*
Thank you, thank you, I'm here all week.
Tip your waitor and try the fish.
We suffer more in our imagination than in reality. - Seneca
In my experience the biggest problem in software development is people (developers, PMs, stake holders, etc.) not talking to one another. And not talking about the next concrete steps to solution of a problem.
Anything that mitigates this problem is a good thing.
Wether it's pair programming, Scrum (formalised rituals of talking to one another) or this "mob programming" stuff. The problem with these methods is, you always have to keep in mind why you're using them: To solve problem #1 mentioned above. Forget that, and you're back to square one, only now you're wasting your time with rituals no one understands or fails to use productively.
We suffer more in our imagination than in reality. - Seneca
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
Why does the description of Mob Programming remind me of this?
https://www.youtube.com/watch?...
Avantslash - View Slashdot cleanly on your mobile phone.
Sometimes I just forget to, or am too lazy to log in. Like now, it seems.
I'm sorry that your imaginary bearded sky fairy didn't smite down those horrible judges for granting people equal rights. That's the thing with believing in imaginary sky fairies, they really don't do anything.
The imaginary sky fairy of whom you speak is our ancestor from Mars. As mars became unable to support human life indefinitely the inhabitants of the planets, humans but we call them Martians, devised a plan to colonise planet Earth, another planet like their own. Originally the pyramids in Egypt, and parts of Central and South America were navigation and astronomical aids. Stonehenge in Great Britain served a similar purpose. As time passed and technology failed we were forced to revert to more primitive social structures and lost was all of our collective knowledge for a few millennia. Your words debase our ancestors and for that you must be put to death. Your passage to an ISIS waystation awaits.
Maybe they should investigate why they have problems with code merges first. Having everyone bunch up in front of one editor seems like a workaround that does not get at the root cause of the problem.
If you use reasonably loose coupling between software components and define interfaces between components before you start writing them and have one and only one programmer work on each component or sub-component between merges you will only have problems with merges if and when someone makes a mistake.
these idiots need to read Fred Brooks' The Mythical Man Month.
Another "methodology" with nothing methodical about it.
so mob programming is better than merging. that's not hard, since merging is by far the all-time worst part of most programming companies.
The solution, of course, that I implemented in my programming company over a decade ago, is to build platforms that don't require merging in the first place.
The benefit of mob/pair/multi programming is that everyone knows what's going on because everyone was there to see it happen. Nothing more.
Every month of so we get a story about some brand new development paradigm or arrangement of coders. That new thing (be that Mob Programming or Angular) can usually be shown to work great with specific problem sets, but as a programmer / architect I am always wary of panacea solutions that propose the best way regardless of the problem.
It's like the ancient philosophical conundrum of defining happiness... it's different for different people.
10/10 same experience here. I suppose they idea was to somehow legalise stupid developers using scrum/agile/other shitty method. Guess what ? it does not work. It is bullshit. Just hire the professionals.
But I actually love code discussions with really smat people with whiteboard or code on screen. But we usually do it in less then 1h and it is at most not programming but discussion. Everyone does his programming later.