"Extreme" Programming

iomud writes "Cnet has an article about "Extreme Programming" the idea being that to code quickly with less errors and minimal integration issues it should be done in pairs. From the opinions in the article it sounds like it works providing a constant state of QA and keeping coders on their toes. Are two heads really better than one?" Its a sorta cheesy article, but some of the concepts are true. Of course, distributed hackers have been doing this for years on open source projects. Its not quite as real-time as they're talking about here, but its fundamentally similiar.

Comments

Re:Extreme Programming == Insult

[rho]

As a (good) "programmer", your responsibilities involve developing the next-level stuff (a QuickTime, CORBA, or HTTP). It is not to produce accounting code for a bulk mail outfit.

However, accounting code for a bulk mail outfit is important, and thus it benefits from a formal, rigid, factory-style coding practice used by mindless drones (or good programmers who might be slumming for the hell of it).

Your coding style and abilities are in no way affected by Extreme Programming. Think of Extreme Programming as a method by which middling programmers (like myself) can benefit from and use to expand upon the High Art produced from good programmers such as yourself.
"Beware by whom you are called sane."

P. J. Plauger

[overshoot]

P. J. Plauger reported in (IIRC) Dr. Dobb's Journal on using buddy-system programming at Whitesmith's. The original reason was lack of seats, but the surprising result was better productivity than when both bodies had access to keyboards and screens.

Seems to be a matter of enforced peer review, which any CS (self included) will tell you is both very hard to get in a corporate environment and essential to good software development.

Re:the zone

[dubl-u]

I agree that this "you can't get in the zone" argument is a straw man.

First off, as other posters have mentioned, it's possible to get in the zone in pairs. This is nothing too shocking; talk to any athlete who plays an intense team sport. When a basketball team is hot, it's like one brain with five bodies.

Second, if one person is on fire and the other is having a so-so day, the so-so person gets the hell out of the way and just provides support until the muses relent. Even in the zone, people make typos, forget cases, and need things looked up. And concentration is contagious in pair programming; if the other guy is working hard, you're likely working hard, too.

Of course, the "what about the annoying guy who is a bad coder and a jerk when working in a team" objection is valid. But there is a clear solution: fire him immediately. XP is a team-oriented method; if a person is incompetent or socially hopeless, they should not be on an XP team.

That doesn't apply to novices, though; pair programming provides continuous mentoring for novices, and keeps them from making big boneheaded mistakes or going off on long, fruitless tangents. So fire the losers (which you should do anyhow) and get good novices in their place.

Pair Computing

[zpengo]

"Pair Computing", the idea having two people to a computer, actually might have some benefits. One person could control the keyboard, and one the mouse (sort of like a pilot and a gunner), therefore increasing the number of frags they can get while they should be working.

Aside from Quake though, it's pretty much useless.

the zone

[wishus]

I find that I write the best code while "in the zone." The zone is that place you go when all your mental functions are in tune with the code you're writing - you lose track of time, you lose track of what's going on around you, and all your attention is on the code.

It's hard to get into the zone, but it takes only a second to come out of it - an interruption from a coworker, a phone call, a noise down the hall...

Obviously, coders still make mistakes while in the zone, but I find that the code I write in the zone is of much better quality than the code I write while out of it.

I think that working in pairs would provide just enough distraction to never get into the zone.

I think companies should focus on building offices instead of cubicles and minimizing interruptions, so that their coders can have more uninterrupted time and do more zone-coding.

Working in pairs may solve some problems, but nothing that couldn't be solved in a code review. Instead, I think the pair idea would distract programmers (it would distract me) and limit time spent coding in the zone.

Sorry for the spacey supernatural superstitious zen stuff, but I know that I sometimes get to a place like that and that's when I write my best code.

wishus
---

Re:the zone

[LionKimbro]

I've had one opportunity to pair code in my life, and I wish I had more, becase from what I've seen, pair coding is the quickest ticket to the Zone.

You may be thinking, "What if I get stuck with Mihoshi. I'm a great coder, what if I get stuck with that jerk down the hall. I'm going to be doing all the work, and that guy down the hall's just going to be bothering me."

[shrug] It's a possibility. What I found, though, was that having another person with me was terribly concentrating, and it was like having laser attention. We'd come up with things that the other hadn't come up with, and it was easy to stay on target. Now I'm single programming, and I get distracted a lot. Sure, there's the occasional Zone time, but I don't know many people who can [alone] maintain Zone for prolonged periods of time.

I'm looking forward to pair programming again.

Re:Burn out?

[scorbett]

I'd be really worried about burning out if I had to constantly code with at least one person looking over my shoulder. Personally, I like to code alone. I couldn't last too long with somebody else nagging/checking my work.

I also (usually) prefer to code alone, but in my last job, I had an opportunity to try pair programming, and I must say it was surprisingly good. One programmer sits at the keyboard and makes code changes while the other programmer sits beside him, hands off the keyboard, and just sits, watches, and comments. You'd be amazed how well this can work at times, the programmer who isn't at the keyboard will have a slightly more objective view, and will be quick to spot any errors that the other makes. Personally, I think it works so well because you've got one guy concentrating on the small picture (the guy at the keyboard) and the other thinking about the big picture.

However, having said that, I found that pair programming can be tiring at times (having someone watch over your shoulder can be taxing), and it can also be boring if you're the one away from the keyboard. Like all things, I think it's best when used in moderation.

--

Re:What the hell??

[Ravenscall]

I think it has something to do with it being a new Corporate catchphrase.

Plus, what better way to get in more young Gen Y recruits to your IT dept. than putting Extreme in front of anything as mundane and corporate as coding?

I am waiting for extreme end user support myself.

Why Extreme Programming is Extreme

[ptevis]

As those who have read Kent Beck's Extreme Programming Explained should know, Extreme was not added for buzzwordness. Kent explains that he takes a number of programming practices known to be beneficial, such as code reviews, testing, incremental development. He views each of these as a dial, since you can do differing amounts of each . Extreme Programming is what results when you turn each of these dials all the way (i.e. "to the extreme"). That's the origin of the name.

BTW, though Kent refers to this as turning the dials to 10, I prefer to think of it as turning them to 11.

Re:Why Extreme Programming is Extreme

[fhwang]

As a further note, XP suffers a bit from the moniker, I think, from managers who hear the name and think it's an extremely risky methodology. It's actually extremely safe, in many ways. Unit Tests help you make sure you can add features and refactor without introducing new bugs. Continuous Integration helps the team minimize code collision and branching. Pair Programming and Collective Ownership help make sure that vital knowledge about the code is spread around among all the programmers, so no one person can quit and fuck up the project.

Of course, alternate terms that would reflect this fact (SafeProgramming? ComfortingProgramming? 40HourWorkWeekSoYouCanHaveALifeProgramming?) just don't seem as catchy.

Shouldn't this be on the FOX channel?

[MongooseCN]

X-Coding, a new tv series to be shown on the FOX tv network. Watch has hackers code under Xtreme conditions like sleep deprivation and consitent badgering from parents to go outside!! Sweat in your seat as you watch these Xtreme coders write scripts that ping flood and create various other dos attacks against their enemies!!!

X-Coding will be shown at 9:00pm, right after X-DataEntry and X-MSCE-Testing.

Damn it.

[xmutex]

I read Extreme Coding and I was prepared to read about guys coding while falling from orbit or snowboarding down the sides of skyscrapers.

Oh well.

Re:Common sense mixed with silly ideas

[Arthur Dent 75]

One, you put two poor programmers together in which case, they both write bad code, only twice as slowly.

No. In this case the two bad programmers will see most of the mistakes the other one makes (it's very improbable that their weaknesses are identical), so the code will be improved and they will learn.

Two, you put a good programmer and a poor programmer together in which case one programmer carries the load.

Even a good programmer makes the occasional mistakes just because he does so many routine jobs. A not so experienced programmer will slow him down and discuss the complicated issues with him. The poor programmer will not make the code worse!

Or three, you put two good programmers together and they try to kill each other and things get done twice as slowly.

Two good programmers could inspire themselves and develop genius and elegant ideas that one of them would never come up with.

OK, if you think of programming performance in some sort of a lines-per-minute output pair programming will spoil your results. But if you consider the quality and number of errors in the code (and believe me, coding errors can be very hard to find) pair programming will drastically reduce the number of errors.

Why does everyone only think: "Hey, there's someone worse than me. I don't want to teach him, if he's bad, he should be fired." Pair programming is one of the few examples for true teamwork.

--

I find that pair programming works best...

[MeowMeow Jones]

When I get the 'asdf' side of the keyboard and my partner gets the 'jkl;' side. He thinks he's soo coool because he ownz the numeric keypad. Little does he know that I get to dictate coding style, since I own the TAB key.

Trolls throughout history: