Slashdot Mirror
"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.
If coding in pairs seems a bit of a stretch to you, you might consider implementing code reviews as a first step. This is where once every so often the project members get together and review a semi-random "representative" piece of code from the project, line-by-line. You'd be amazed how many little ambiguities and kludges are found this way that you'd forgotten about.
The results are less dramatic than those advertised here, but still worthwhile for something that lasts no longer than a standard project meeting.
User stories do not equal "requirements gathering". User stories are a specific type of requirements gathering by generating informal use case scenarios, usually in close cooperation with a customer (present or by proxy).
Release planning does not equal a project plan. Releases in extreme shops occur far more frequently than the typical "project plan" can digest, let alone represent. Calling release planning "project planning" assumes top-down dictatorial management.
"Project velocity" does not equal "hitting milestones". Milestones are not negotiable, nor do they provide particularly good resolution. Milestones also deny the ability for the team (remember, the ones actually doing the work) to reorder feature development to meet customer requirements.
Moving people around is just fine because release planning results in lots of micro-projects of a day or three each, certainly no longer than a week, whereas standard planning might hand a three- or four-week project to an engineer. Engineers pair themselves off, depending on who might have the skills or experience helpful with some particular or general module or subsystem.
Application services generally do have a representative customer available, or can easily enough get one through various incentives. Internal applications almost always have a user available. eXtreme Programming Explained offers suggestions on getting a representative customer while keeping them connected with their usual roles and duties. If you don't have a representative customer, appoint someone (perhaps the CTO would be easier to live with as a customer than as a taskmaster).
Code must be written to agreed-upon standards. The difference between extreme and non-extreme shops is whether the standards are reached by consensus among skilled engineers or some manager with a stick up his arse.
Writing unit tests first is almost always possible, if your code is sufficiently self-contained (no intervening web servers or the like), and rarely impossible even then. An important hidden benefit to writing unit tests first is that you're forced to use the API before implementing it, raising any necessary warning flags before you implement something unusable. Of course, the usual benefits of unit testing still accrue. You also use the unit tests to answer the question of whether your code is done yet. Once the entire system with your code passes all unit tests, stop working on the code and write some more unit tests to try harder to break stuff. This stratagem is very useful outside of extreme as well.
"Only one pair integrates at a time" is an artifact of the author's preference for Smalltalk, whose development environment is not like the C development environment most of us are used to. You can safely ignore this one; I do.
Pair programming produces code at about the same rate or slightly slower than the two programmers working separately, but in all cases faster than one programmer flying solo. You can't guarantee you get good code from the solo programmer, either, but the simple fact is most problems in software are the result of a moment's inattention to some detail that a fresh pair of eyes is more likely to catch. The Explained book offers more detail on how to pair programmers effectively.
Did it improve performance? Would anyone's name beside "Big Blue" and "800lb Gorilla(tm)" appear on it after it shipped anyway? Does anyone care besides you?Again, extreme is useful in situations where the requirements are vague or changing. The corollary is that it's not as useful in implementing a set of specifications legendary for its clarity and completeness.
"Collective code ownership" is better expressed as a rule: "Anyone who can add value to the code is required to do so at any time." Failing this, either no one owns the code or each individual owns their code. The former is prone to corporate finger-pointing exercises, blame-laying, and a general tendency to not care. The latter is prone to ego trips (as seen above).
As Explained puts it, "That's fine. You just can't work with us." Extreme is just another tool in the software engineering management toolbox. It works where it does. It doesn't work so well or at all where it doesn't. Sorry about that.
-jhp
/. -- the Free Republic of technology.
Here's the dirty little secret behind XP and most other Wonderful Methodologies.
They require a set of passionate and skilled programmers, and a smart and charismatic team leader. Given that, XP will produce excellent results. And so will pretty much any other method.
The inventors of these things are invariably those types of exceptional leaders needed, and they gather a team of highly skilled engineers, so the results from their projects trying out their new ideas will be exceptional.
Meanwhile, many real projects are plagued by incompetent, combative engineers and managers, who jump ship at the most inopportune moments. Figuring out how to get good results in that environment is much harder and messier.
This has very little to do with the "open source movement."
Having two people sitting in front of a computer, looking at the same code at the same time while one of them is writing it is very different from having two different people looking at code a day later, with no knowledge of the thought process involved during its creation.
I know the open source movement wants to somehow take credit for everything, but you can't.
First off, the whole idea of collaboration has nothing to do with open source. It happens all the time with thousands of programmers inside companies, all the while keep the code closed.
Open source doesn't seem to work any better than closed, and nobody is making any real money at it. So if it's not better, and makes less money... well you can finish that thought.
The pair programming angle is minor and unnecessary.
It's really about the software project change cost-curve paradox: that it is only in implementation that most design flaws can be found but that at that stage it's too expensive to make the required design change, so hacking occurs.
XP allows a design change to be propogated controllably through the implementation model avoiding twisted topologies.
The change in philosophy is a hard sell to management who have only just got their head around the (in my opinion now discredited) UML.
DDJ columnist Verity Stob reports her experience with XP here. Check it out -- it's an interesting read. While you are at it, you could also read her dig at Slashdot in this month's column.
yes, working in pairs definitely has its advantages, but there are some serious disadvantages too. i'll extrapolate on both:
:) ]
advantages:
not only does the work get done quicker, there's now two views on the problem, which can often realaly simplify things. For example, I might be having "coder's block" while trying to figure out how to write an algorithm, while someone else might immediately see a way to do it. (The history of public-key cryptography is a perfect example, how a man (i forget who it was) figured out the mathematical formula within hours when the british government had been trying to find an implementation for a decade)
Additionally, as cheesy as it sounds, working in pairs provides moral support. when a project is extremely time-consuming, one can lose interest in it, but with two people, there's always one who can take over while the other takes a break. Now if both lose interest, you're absolutely fucked, but hey...that's how it goes.
Having too many people on a team causes confusion, finger-pointing, nobody wanting to do the work, etc...pretty much the elements most management systems have.
The primary disadvantage of working in pairs is that one might be "in the zone", and be able to code for hours straight, without error, but having a partner would slow him down, and prevent the natural abilities of "the zone" (i'm sure you programmers know what i'm talking about)
My opinion on teams is that it would be great, as long as the members realize each others capabilities and respect each other's privacy (in that if someone's coding, and has the office door shut, **don't** bother them.)
All in all, a partnership with the right people and the right ideas would work great...the problem is its usually management who decides who'll be on the team, and exactly how they're going to work together. And we all know what happens when management gets involved in coding...
[I'll leave the obligatory 'Windows' remark to you
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. Hell, I don't even like code reviews. Generally, when I work on large projects, we agree to a standard coding method, naming conventions, etc. then go to it. With decent developers, generally you don't need to check in constantly. Besides, just day to day workflow prohibits it. I code for a few minutes, get a snack, code for a few minutes, check Slashdot, etc. If I couldn't do that, I don't think I'd be a programmer (at least at that company) for very long.
Behold the american work ethic:
"If no one is watching, I'll get lazy, (do) cut-and-paste programming, no test writing, no re-factoring--the sort of anti-patterns that make software suck," Extreme programmer Lyle Hayhurst said via e-mail. "If someone is watching me, I'll probably feel guilty and do the right thing."
Let's have a quick look at extremeprogramming.org...
user stories = requirements gatheringrelease planning = project plan
project velocity = hitting milestones
moving people around... now this can be a very good or very bad idea. You definitly don't want all your eggs in one basket, but you also don't want to switch someone to a different task just as they're hitting their stride.
The customer is always available = wishful thinking
Code must be written to agreed standards = common sense
unit test first... I would say this could be a good idea, but I suspect that it's impossible more often than not. And when there's scope creep and the deadline's tomorrow, do we update the test plan first? yeah, right.
pair programming... this *may* work for *some* programmers. Writing code takes man-hours. If you put two people on one task, unless that task is done at least twice as fast, you lose. And there's no guarantee that you'll get better code. I see three scenarios, none of which are good. One, you put two poor programmers together in which case, they both write bad code, only twice as slowly. Two, you put a good programmer and a poor programmer together in which case one programmer carries the load. Or three, you put two good programmers together and they try to kill each other and things get done twice as slowly.
Only one pair integrates at a time... this is an extension of pair programming. If you reword this to "only one person integrates at a time" that's source code control! Except that with good communication, more than one person can integrate at the same time assuming they're in different modules.
Collective code ownership = chaos. I once wrote a TCP/IP layer for a big blue 800lbs gorilla. The code was complete, it entered testing, and was half way through (two weeks worth of testing!) when one of the other programmers decided to rewrite a section of my code suposedly to improve performance. So let's see, someone else's code with my name on it. Great!
Leave optimization till last = common sense
Maybe I should invent my own methodology! I could make millions! I can make up my own jargon!
Doesn't this all sound a bit too much like scientology?
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
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."
Potato chips are a by-yourself food.
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.
Lacking <sarcasm> tags,
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.
Aside from Quake though, it's pretty much useless.
Got Rhinos?
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
---
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.
You say you want a revolution....
BTW, though Kent refers to this as turning the dials to 10, I prefer to think of it as turning them to 11.
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.
Outdoor digital photography, mostly in New Engl
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.
jack's bicycle is music to my ears
Trolls throughout history:
Trolls throughout history:
Jonathan Swift