| I exaggerated to make a point. Of course you'd work with folks. Apologies for the hyperbole. You have a good point, but consider this: the team is in the hook for whatever the code is anyway, whether there are disagreements or not. So the real question is whether or not you surface those disagreements (or bury them, in your example), or simply don't address them at all. I'm thinking you surface them, even if the herd mentality moves in the wrong direction. Unfortunately, unless you can deliver the entire thing on your own, social skills count as much as technical skills. The bigger the team and the more people think "that's not my job", the more the team norming becomes more important than the implementation details. Or -- to continue with the hyperbole -- if you get it wrong, and you all get it wrong? You did your best. If you do a great job and the team flops? The guy paying the bill isn't going to be so happy with "Yeah, but if they had only listened to me...." Your job is to make the team/project succeed, not be the best coder. Mobbing is still in the hype cycle. I remain wary, but cautiously enthusiastic. It'll probably be another 2-3 years before all the warts come out. |
I think it's a cool idea. I'd still worry about people taking over, coasting, checking out or otherwise not getting to express themselves, but realistically that's a constant concern anyway, regardless of whichever development structure you take.
But I'd try it. I'd be exhausted, frustrated and very much in need of a drink after the first day, but that says more about me than it does the approach :-)