Slashdot Mirror
Coders, Your Days Are Numbered
snydeq writes "Fatal Exception's Neil McAllister argues that communication skills, not coding skills, are a developer's greatest asset in a bear economy. 'Too many software development teams are still staffed like secretarial pools. Ideas are generated at the top and then passed downward through general managers, product managers, technical leads, and team leads. Objectives are carved up into deliverables, which are parceled off to coders, often overseas,' McAllister writes. 'The idea that this structure can be sustainable, when the US private sector shed three-quarters of a million jobs in March 2009 alone, is simple foolishness.' Instead, companies should emulate the open source model of development, shifting decision-making power to the few developers with the deepest architectural understanding of, and closest interaction with, the code. And this shift will require managers to look beyond résumés 'choked with acronyms and lists of technologies' to find those who 'can understand, influence, and guide development efforts, rather than simply taking dictation.'" Update: 04/04 19:52 GMT by T : InfoWorld's link to the archived version of the story on open source development no longer works; updated with Google's cached version.
And for the record: a few years ago there was a study published in Communications of the ACM that showed while pair programming is more efficient than a single solitary programmer, it is not as efficient as two programmers with two keyboards. FYI.
That's one study. I imagine the one you're talking about is "All I really need to know about pair programming I learned in kindergarten" by Williams and Kessler. This study has been criticised for its focus on performance over and above accuracy. I'd suggest you look at some of the broader studies that have been published since that one, e.g. Williams, L. Kessler, R.R. Cunningham, W. Jeffries, R. "Strenghtening the case for pair programming" (IEEE Software), finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently, but more importantly a 13-17% reduction in the number of bugs discovered after signoff, whereas you would usually expect an increase with two programmers working independently. Nosek 1998 (also a Communications paper) found a 41% speedup, which is less than you would expect from two programmers individually, but also found a 43% increase in evaluations of code readability and a 33% increase in evaluations of resulting functionality of the software developed.
So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code, the code produced during pairing is more likely to solve the problem that it was actually required for, and will be more maintainable afterwards. And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on, thus helping the team maintain the software at a later date, or that most programmers find they can keep up pairing for longer periods of time than they can code by themselves, or that job satisfaction is generally higher for programmers who pair.
And your description of how you think when you code betrays that you have dismissed this without trying it. You think differently when you're pairing. It's just as effective (if not more so), and the interruption is not a problem.
Stereotypes aside, that's basically true. Except for the programmers being poor spellers, etc. It's not programmers. It's really pretty much everyone that's graduated in the past decade or so. That might be some hyperbole, but it's not far from the truth. I mean, just look at how the 30+ crowd writes, and then compare that to today's high school graduates. It's chilling.
I give you exactly the same reply I gave the person above: If you really believe that, then you have never worked in a real Agile shop. My experience has been quite different, and I know quite a few people who would say the same.