I’d be interested in reading posts from you about Steve Yegge’s latest rant.
Re:See Keithb's reply
Aristotle on 2006-09-28T18:17:37
I know. I read almost the entire thread, and that is the first objection that came to mind anyway. Still, Iߣd like some opinions on specific items, eg. from people who have had good experiences with pair programming.
Re:See Keithb's reply
Dom2 on 2006-09-29T11:25:22
Personally, I find pair programming to be a huge gain in productivity. Not because it helps you work faster, but because you've got somebody there, I don't slack off the whole time. Email gets left till later. Blogs can wait. I'm a big fan of pair programming.-Dom
So let me see if I get this right. This guy thinks that Agile development sucks, but Google's strategy of throwing buckets of money at developers and letting them transfer from project to project at a drop of the hat and spending 20% of their time on personal projects is the way to go. Riiiiiight. Tell that to a 3-person, cash-strapped startup. One of the things that XP stresses heavily is that you must customize XP to fit how your company works. Paint-by-numbers doesn't work for software development. Oddly enough, Google appears to have customized software development for how their company works, but Google's not your typical company. Google's not cash-strapped. Google isn't exactly an example which can be generalized. In fact, let's take a look at a ridiculous assertion:
Google isn't the only place where projects are run this way. Two other kinds of organizations leap to mind when you think of Google's approach: startup companies, and grad schools.
Well, not having been to grad school, I'm hardly in a place to comment, but startups? Been there. Done that. So have plenty of my friends and coworkers. Let's see what startups generally don't have:
While startups admittedly have Google's apparent lack of bureaucracy, trying to claim that the other key incentives Google offers are applicable is outrageous.
That's not to say the guy's rant is worthless. Pair programming is difficult. At best, I've seen pair programming slow down development. However, it's a constant training program for large systems, teaching developers how other parts of the system works. Did your lead developer accidentally run his head through a meat grinder? Oh well, everybody else knows the code because they've paired with him. Now that's the best I've seen of it. A slight slowdown in productivity gets traded for a constant training program which makes companies not beholden to individual developers. Also, I've noticed that programmers spend less time reading digg and other sites when they pair. Their conscience is sitting next to them.
At it's worst, it gets really bad. One nightmare I've had to deal with is the programmer who apparently believes soap touching his crotch is against his religion. He would open his legs and I'd try not to vomit. However, that's a problem regardless of pair programming. The pairing only exacerbates it. A more subtle problem is when you have to pair with the programmer who's so incredibly boring that all of his pairs fall asleep (I've seen this, believe it or not. This guy was allowed to work alone because he was so good, but no one else could maintain his code.) The most common problem, though, is developers who have such different ideas about how code should be written that they constantly squabble about it. I've seen a lot of that.
Unfortunately, while the guy really had fun ripping into pair programming, you'll notice something he didn't do: explain the rationale behind it. He tried to but he got it spectacularly wrong. I suppose I could have fun ripping into computational linguists for the idiocies of their field, but since I don't know squat about it, I'd look just as silly.
So how do most companies really work? Most companies I've seen, and those my friends tell me about, are pretty similar. "Project Management" is something they tell their customers, not something they actually employ (I've worked at companies with a strong commitment to project management. It's not always a good thing). Cowboy coders working with incomplete and innacurate specs would still manage to get stuff done. But the stuff they delivered was usually bug-ridden, didn't always satisfy customer needs and was delivered late, to boot. However, in a small company, if you have enough revenue to keep going, you can overcome these hurdles and muddle through. As your company grows, if you can't overcome these, you're doomed and I'll explain why (and how agile methods can help).
The main problem with large projects is uncontrolled search costs. Search costs are the costs associated with acquiring information (what are the specs, dude?) However, information has three primary qualities, any of which, if missed, seriously degrades the value of that information and artificially inflates search costs. The information must be:
In the small cowboy company I described, you can satisfy those by turning to your boss, who sits next to you, and say "what do I do now?" It's pretty easy. You still might churn out crap, but you have a clear direction. As the company grows, the boss is down the hall. As it grows further, the boss is often on another floor. Projects start to flounder and "project management" begins. For most styles of project management I've seen, while it's possible that the information is complete and correct (and this is a crap shoot), it's virtually guaranteed that it's not timely. I had one company put me on three projects at the same time because they knew I'd be waiting so long for information for each of them. Eventually I'd return to a project and try to remember what the hell I was doing.
But what if the information isn't complete and correct? Well, if the feedback (also information) let's you know what's wrong you still have to wait to find out you were wrong. Oftimes this means going back and undoing code you've written in the interim or trying to understand what you were doing four weeks ago when you turned your work in. Me? I can't remember what I was doing four days ago, much less four weeks.
With agile methodologies, while they do have difficulties, they concentrate very heavily on making the information satisfy all three of the above criteria. When implemented correctly, one of the biggest problems with large projects just goes away. You never wonder what to do next. Can't remember the spec? Pick up your story card. Don't have anything to do? Pick up another story card. Is your code wrong? You find out immediately. I've seen agile methodologies work fabulously, but if you don't understand how the various bits work or what they're trying to achieve (and the author of that article didn't seem to), then you're just as likely to fail with agile techniques as you are with waterfall or cowboy.
Re:Wow. Talk about a big bucket of suck!
djberg96 on 2006-09-28T19:12:44
I have no idea what he's talking about with grad school, either. If left to their own devices most graduates students would take another semester (or three) to finish their thesis.Of course, my experience is from a guy who studied Roman and Greek history at graduate school, not CS.
:) Should we even discuss doctoral programs?
;)
I wrote furry Star Trek fanfic in response at This Chocolate Cake Recipe Tastes Terrible!
Re:Let's All Work for Google!
DAxelrod on 2006-09-30T19:21:39
I must have laughed for about five minutes solid at this response. Then I read your article and was impressed you kept the furry Star Trek fanfic not only worksafe, but relevant.Re:Let's All Work for Google!
chromatic on 2006-10-01T06:35:39
Thanks! I think the secret to being outrageous on the Internet--without losing all of your credibility--is to have a sense of style.
