Mob Programming: When Is 5 Heads Really Better Than 1 (or 2)? 126
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.
Hypersupervised programming? (Score:5, Insightful)
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".
Re: (Score:2, Interesting)
You make a good point. If that's the only way to get code reviews done, though, there's something terribly wrong with the world. Most of these social interaction "innovations" are thought up by people that don't understand that some people just like to be left alone, and work better that way. While I am one of those who like to be left alone while working, I feel that a competent code review is an important part of the development process. Too bad many of my previous employers either didn't think so (on
Re: (Score:1)
Probably the same people that believe tossing a bunch of devs into a single room produces more and better software than giving them quiet offices where they can actually think without being interrupted all the time.
Re: (Score:1)
I can't review code while chatting and looking over someone's shoulder. Nor can I concentrate on programming while people are looking over my shoulder. I need to be left alone with the program for a while, then when I have accomplished something I can discuss it with other people. In my experience it's rare that >2 people are so much in tune with each other that they can effectively work as a group all the time, and with introverts like me it probably doesn't work at all because I can't think and talk co
Re: (Score:2)
Meanwhile inside Google (Score:3)
"We are all Eric"
"There used to be 11 of us"
Re: (Score:2)
question about this (Score:1)
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?
Re: (Score:2, Insightful)
Re: (Score:3)
Another complication is introduced with outsourcing. Before, the manager was responsible for hiring and staffing t
Re: (Score:3)
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.
Re: (Score:2)
You ask that question as if it were a bad thing....
Mob Programming, huh? (Score:5, Insightful)
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.
Re:Mob Programming, huh? (Score:5, Insightful)
When I hear of group-programming styles like this, I always think of a network of modern multi-gigahertz computers, all linked together over a 1980's-style 10MB/sec Ethernet LAN.
Whatever benefit the additional CPU cycles might add is more than taken away by the low throughput and high latency of the communications medium. (What is the average throughput of a spoken conversation, anyway? Maybe 1200 baud on a good day?)
Re:Mob Programming, huh? (Score:5, Insightful)
Keep in mind that human beings are pretty good at creating a shared mental context of their conversation, and programmers would also have a lot of shared knowledge, both of the problem at hand as well as more generalized knowledge that most programmers (should) know.
For instance, if I said "We should use a proxy object here to create a streamlined interface and minimize coupling between these various systems"... how much information did that convey? If you're a programmer, that probably said a quite a bit in a very few words, because you understand a deeper meaning behind all those words.
I guess you can consider shared knowledge to be a highly effective form of compression for personally-transmitted information (spoken communication is only part of it, remember).
Re: (Score:3)
For instance, if I said "We should use a proxy object here to create a streamlined interface and minimize coupling between these various systems"... how much information did that convey? If you're a programmer, that probably said a quite a bit in a very few words, because you understand a deeper meaning behind all those words.
Been programming for a long time. That sentence is useless. Its meaningless speech you direct at your manager who doesn't know what you're doing.
That may have meaning to people very involved with the project, but only if you're all on the exact same page, which is pretty much the case never.
Keep in mind, that even though slashdot just rediscovered the practice, this 'style' has been done before and it universally sucks.
This is nothing but a rediscovered fad for people who can't actually code but think the
Re: (Score:2)
Keep in mind that human beings are pretty good at creating a shared mental context of their conversation
You also assume a certain amount standard knowledge and understanding among the peers in order to have a "shared mental context". Depending with whom I am talking, I may need to dumb down my vocabulary or complexity of ideas. If I toss out the phrase "scalable lockless eventually-consistent datastructure", it is going to WHOOSH over 99% of the people I talk to. Now I need to spend several days trying to get someone up to speed with the concept, but they probably won't fully understand a lot of what I'm talk
Re: (Score:2)
Well, in that respect what's the bandwidth between the user and the computer over the keyboard? If the primary purpose was communication and not implementation, you have a thousand tools for that which at best are equal to a meeting room with a whiteboard. They're trying to mash up the traditional system where you agree on what to build then go off to build it so that you're doing both at once all the time. To me it smells like jack of all trades, king of none where you need to deal with everything from hig
Re: (Score:2)
(What is the average throughput of a spoken conversation, anyway? Maybe 1200 baud on a good day?)
1200 baud is actually a pretty accurate guestimation.
75 and 300 baud was way slower than my reading speed.
1200 baud was the point that certain cases (say transferring an ascii text file) was pretty much equal or just slightly faster than reading speed, only balanced out by the relatively slower ANSI "box" characters being added to the mix and/or ANSI color codes that took more bytes to send.
2400 baud was the point things were beyond reading speed by a large enough amount that most all "baud frustrations" di
Re: (Score:2)
Absolutely wrong. If this was right, "design by comittee" wouldn't be a synonym for utterly fucked up. And the bigger the group, the more likely you are to just pick something to get the fights over with.
Re: (Score:3)
"Absolutely wrong. If this was right, "design by comittee" wouldn't be a synonym for utterly fucked up."
Point being that those in the comittee are good at reaching places at comitees, not necessarily good at the problem at hand.
In other words: "designed by comittee" is a synonym for "uttelry fucked up" because it never happens that the ones that can solve the problem are at the comittes but their managers. Imagine a world where the solvers instead of their managers were at the comittee.
Re: (Score:3)
No, design by committee fails because no matter how good the people are at their job, as you increase the number of people involved differences in opinion and politics magnify. Design by committee fails even if you have the best and brightest on the committee.
Re: (Score:2)
So you break down coding to it's elements and create sound logically structure. You do not want all coders, churning out code, you want to break down coding, it's application it's final result into all the tasks required to achieve a successful outcome. So code researchers, who gather information on the problem to be solved, who define and layout the problem. Next code describers, who describe the problem in coding terms and break down the problem into it's various coding elements. Then you have coders who
Re: (Score:1)
The more people in the group the more each of them cares about having their ideas pass and the less they care about getting shit done. If putting a bunch of people together were a good idea Congress wouldn't exist.
Re: (Score:2)
Perhaps you should form a committee to decide which spelling to use, for the sake of consistency.
Re: (Score:2)
Design by committee often fails, in my experience, if you have a group of equals on the committee and no one is empowered to make the final decision, or is not willing to make the final decision when it needs to be made.
In this sort of programming environment, I'd think it would be critical to have at least one person with the authority to make a final decision on any matters of disagreement or contention - likely the senior programmer when it comes to technical issues, or the feature/product owner when it
5 H1B's are better then 1 avg coder and chepaer (Score:1)
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.
For the love of God... (Score:1)
...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...
Re:For the love of God... (Score:5, Insightful)
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.
Re: (Score:1)
We're converging on infinite monkeys. Code quality will be awesome.
Re: (Score:2)
You forgot salesmen, which is probably the biggest block of promoters of these fads.
Re: (Score:3)
It's all about the environment... (Score:2)
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.
Seriousl
Re:It's all about the environment... (Score:4, Insightful)
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.
Re: (Score:2)
Fortunately everyone in my office bathes regularly, but we do have an office manager that believes too much perfume is merely a starting point. Seriously, I'm four cubes down from where she works and I can tell when she's arrived to within five minutes.
Re: (Score:3)
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 t
Re: (Score:2)
Just because I've got an office doesn't mean I can't walk down the hall to collaborate when I need to.
Re: (Score:2)
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.
That's because the goal isn't to be productive, it's to remind the plebs of their places. Offices are reserved for those who are higher in the organisation, not those who require offices. It's a class system and its' designed to remind you that you are the cattle.
The occasional loyal worker will, of course, argue that open-plan is better ("collaboration", "exchange of ideas", etc), but that's because they consider themselves important enough to the organisation that they will one day get their own office -
Re: (Score:2)
- Get the right people together: don't mix programmers or analysts who need to focus with people who are likely to be on the phone all day.
- Don't do hot-desking; give everyone their own desk
- Provide plenty of quiet booths for a single occupant, rooms to have meetings in, and a coffee corner away
Re: (Score:2)
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.
Well I've been waiting for this since 1994, so don't hold your breath.
Fortunately for me the company I currently work for instituted a 'work from home' policy for employees who lived "a long way away". I decreed that 10kms was "a long way" and basically stopped showing up. If they ever object I will immediately quit because I can literally feel my blood pressure rising when I sit in an open plan office and have got to the point in my life where my health is more important than my career.
Fuck! Open! Plan! Of
Re: (Score:1, Informative)
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.
They're fixing that. Their getting rid of the 6-figure programmers, and replacing them with minimum-wage programmers from India. Then the balance between the cheap-ass cubicle space and the cheap-ass programmers will be restored.
Arguing ensues (Score:2)
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.
Re: (Score:1)
Hit the high points, I think :). Haven't tried the mob stuff myself either and hope I never have to... but it would be handy to have a workstation around that's not anyone's personal desktop/laptop for quick ad-hoc learning sessions.
Seems to me that most teams could do this easily and just don't think of it. Rather than having formal scheduling for group work, just put together a VM sandbox in a kiosk (common IDE/command line/barebones stuff) mode, snapshot it a couple times a day, and steam the screen/inpu
ROI (Score:2)
The Tao of Programming... (Score:2, Insightful)
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 (Score:2)
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.
Re: (Score:2)
Really, that's the answer to all of this, isn't it? Competence? Aren't many of these fads intended to be a substitute for basic coding competence, which, sadly, I've found to be rarer than we might wish?
And ultimately, the fads fail, because in order to produce a good product, competence can't be eliminated no matter what. But the big downside is that when truly competent staff are forced to get bogged down in all the management dictated faddish-ness, they can't produce and look nearly as bad as everyone el
Re:Or, you could quintuple the salary (Score:5, Funny)
Redundant Array of Incompetent Developers.
Mob dev is design by the least experienced (Score:2)
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
Re: (Score:2)
> There's a problem with mobs: they gang up and lynch anyone who isn't part of the mob.
Democracy often feels that way. It's not necessarily true, in the first meetings, even if it feels the same as later when it is true. Saying it always happens, is not realistic.
Possibly a band aid for poor code organisation (Score:3)
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.
Re: (Score:2)
You may have noticed me mention that we push quickly into our repository, the article mentioned developers trying to merge a week of work
That's the problem. If you merge quickly, merging is usually painless. If everyone saves a week of work for merging, it can get really painful.
Re: (Score:2)
Re: (Score:2)
This doesn't happen if all the details are nailed down. If you ever find such a project, with all the details nailed down, that isn't in one of those fields where they spend lots of money for verification like NASA, I'm sure you could charge programmers admission to go in and see it in amazement.
Re: (Score:2)
Re: (Score:1)
Someone linked me to this discussion. Nice to read something thoughtful on the topic. I'd like to give you some context and then clarify a couple of aspects of the way we use mob programming.
First, some context. We were asked to develop 3 embedded home control devices, 2 of which have LCD user interfaces and 1 of which connects to a cloud, from the ground up in ~1 year. They allow you to do complex stuff like set up multi-channel heating schedules and bind to a 868mhz radio network... wi
Mob programming ROCKS. (Score:1)
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 fro
Re: (Score:1)
"How could this possible be better than using git and having a sane version history."
For starters, we have really good collaboration. Someone could be writing code, someone else notices fucked indentation or syntax, an can fix it on the fly while explaining what's going on.
"And if you are what possible advantage is there for everyone logging into one system - and you being local"
Most of my devs are in other countries. Waiting for everyone to do their thing, submit, and have to dig through shit to see what d
Re: (Score:1)
I'm not going to say that I make sense. I'm just parroting my personal experiences in managing and coding various projects.
It only makes sense to those that are not afraid to admit that they are wrong and have encountered this same problem of which I speak.
I thank you for the praise, however! It is rare I see MOB programming get any credit of any sort.
It's for kids, silly (Score:2)
"... 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.
Goverment construction workers (Score:2)
Looks like they put a government construction worker in charge of a programming team.
prototyping at a bar (Score:1)
'The mob' programming (Score:1)
Two better than one, six better than two, so ... (Score:2)
That brings back memories (Score:1)
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.
Are 5 heads better than 1 (Score:1)
some factors to take into account (Score:1)
How are they getting their metrics? (Score:2)
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.
Pair/gang programming doesnt work. (Score:1)
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.
More complex projects (Score:2)
"I will offer him an interface he cannot refuse" (Score:2)
*Tadum* *Crash* *Thud*
Thank you, thank you, I'm here all week.
Tip your waitor and try the fish.
The biggest problem in software development (Score:2)
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
When the one typing isn't slow as molasses (Score:3)
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.
Two idiots one keyboard (Score:2)
Why does the description of Mob Programming remind me of this?
https://www.youtube.com/watch?... [youtube.com]
Code merges? (Score:2)
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.
uhuh. (Score:2)
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.
As fallacious as asking "Which Language is best?" (Score:1)
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.
Re: (Score:1)
==UserScript== @name Nuke anonymous cowards
http://pastebin.com/7tsPe2X6 [pastebin.com]
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!
Re:Userscripts in pastebin (Score:2)
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 [pastebin.com]
Re: (Score:2)
Well, it is on topic, because it stands as counterpoint to mob programming.
Re: (Score:2)
... which was probably what caused the problem in the first place.
Re: (Score:3)
Getting rapped by buch of programmers is worst experience ever.
Yeah, it's pretty bad [youtube.com].
Re: (Score:1)
Hah, nice shout-out to Pomona, but Google Maps says that bar is in St. Louis.
Re: (Score:2)
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 spre