"Extreme" Programming 288
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.
Re:What the hell?? (Score:1)
Taco please........ (Score:1)
Re:What if your partner is an asshole? (Score:1)
Re:Extreme Programming == Insult (Score:2)
I've yet to find any OO programer (C, C++, Java, whatever) who doesn't dig patterns. It's like adding a whole level of abstraction and abbreviation to your conversations. When you say "factory method" the other guy instantly knows what you are getting at.
But then perhaps you meant something else?
Re:Toned-down pair coding: Code review. (Score:2)
If you can't take someone looking at your code at pointin out bugs you should not be a professional programer. Life involved dealing with stuff like this.
Good, but one minor point (Score:2)
However, the Slashdot header implied that XP is good for larger projects. In fact, it's never been tried for large projects, and its creators claim that it's possibly not a good idea to attempt it.
Of course, I'm sure the author was thinking of "larger than one person" projects, but he didn't explicitly say so. So I thought I'd throw out the warning.
-Billy
Re:Pass on the Mountain Dew (Score:2)
The myth that 60/hrs a week constantly == a great project is utter BS. I've seen too many people worked into the ground when they really needed to admit that the entire project was flawed and needed to be re-examined.
Re:Extreme Programming == Insult (Score:2)
There, I got it out.
Good programmers see the value in approaches that maximize the benefit they provide to the project as a whole. XP (via pair programming, which acts as a mentor/apprentice model often) encourages this.
Good programmers know enough to test and re-test. XP definately encourages this.
Good programmers know not to re-invent the wheel, and they also intuitively see larger patterns evolve over the course of hundreds of programming projects. Design Patterns simply make sense, they are not "formal", nor "rigid", it's simply a way to discuss something that already exists, and that you see clearly if you're a "good" programmer.
So what are you afraid of?
Re:Extreme Programming == Insult (Score:2)
That having been said, use what works. If it doesn't work, try something else. I don't shoot people who write procedural code using Rational Unified Process... (I just pity them ).
Re:Extreme Programming == Insult (Score:2)
I'm sorry you feel this way. I hope I never have to work with you. Life is best enjoyed when your work (even on someone else's dime) is fun and enjoyable...
And even though I find the relevancy a little low, I prefer 2-space indentation, but I'm forced to use 4 at work...
Re:Extreme Programming == Insult (Score:2)
Patterns, XP, OO all have great ideas, but your mind (and your work) suffers when you follow them too strictly.
Each problem has its own ideal solution, which is uniquely tailored for the situation. A particular pattern, no matter how elegant and simple won't be the best solution a lot of the time, but pattern-drones will apply it anyway.
I've seen too much awful code due to people rigidly following a dogma, when the solution was much simpler..
Sometimes procedural code makes more sense, even when coding in an OO environment.
Re:I find that pair programming works best... (Score:2)
You guys are suckers (Score:2)
OK, we all know that if there was somebody else in the cubicle with us, we would be working instead of reading
Re:Common sense mixed with silly ideas (Score:2)
Customer always available: Actually, that's often possible. And once you've delivered one project like that, it's much much easier to get business buy-in to doing it again.
Unit test first : It's possible more often than not. If there's scope creep, and you're changing code, then those tests save your bacon - if your change creates a bug, are you going to rely on luck to spot it, or in the unit tests that always passed 100% until you made the change? And which is most likely to point out where the bug is? Trust me, when refactoring or changing requirements (which leads to refactoring) unit tests become worth double the effort of creating them.
Collective code ownership : if you have unit tests, and run them every few minutes (don't laugh - we do - 141 tests in 23 seconds) it's pretty sodding obvious that you've broken the code. So nobody breaks it for longer than a few minutes, as they change, run tests, spot the break, fix it.
Pair programming: Maybe your ego prevents you working with someone. Most intelligent people seem to manage fine.
Please, don't go dissing techniques you haven't yet tried. I've been trying them, and there are flaws, and I'm publicising them within my company. But there are also major benefits, and I'm sharing those.
~Cederic
Re:Burn out? (Score:2)
You find that you get into the zone, even in a pair, and 3-4 hours fly past. Then you'll take an hour break, read email,
Nagging doesn't happen - if you are following the method and standards then there's nothing to nag about. The partner has to be pretty sensible though.
I've been programming for 7 years (commercially - 18 otherwise) and I'm pairing with a guy that's done 12 years commercial (+ extra) so we're not exactly newbies. And we're better than most programmers in our company. Yet we both recognise that our paired code is better than our standalone code. And we've both learned stuff on the project.
So unless you're a complete cowboy, or have BO that kills at 20 paces, you should be fine in pair programming.
~Cederic
Re:yes and no (Score:2)
Hmm, one of the principles of XP is that nobody sits in an office alone coding. ALL code is pair programmed - otherwise you get bad code.
We've zoned as a pair - it's a scary experience, but it can happen.
As for nobody taking responsibility - please accept my sympathy if that's the culture where you are.
The idea with the team is that anybody in the team can pair with anybody else in the team. And that's good, because everybody gets to coach and learn from everybody else. And don't think that new guy can't teach you anything - I've yet to have a newbie programmer working for me that hasn't taught me something new.
I'm not surprised that so many people here on
~Cederic
Maybe I'm a bit off.. (Score:2)
I don't understand why people take it as a literal thing: you needn't follow their cookbook example of pair programming or whatever. Look at the methodologies, look at what's wrong in your workplace, and adapt. If it works, good. It would seem to me that there's less chance of things getting worse.
Which leads me to my second point: it never appeared to me that XP was aimed at the Apache Foundation, or the KDE team, or other large, distributed, open source/free software projects. *I* always thought that it was aimed at the larger development houses: the mainstays of development. If a free software project likes XP, fine, great, but its aimed more at a large company than a group of people who are on the same page to begin with.
My last point is that a lot of it seems aimed at managers, not necessarily the pointy-haired kind, rather the ones who were probably programmers at one point and got pushed into management. It gives them a means to make change - a manager, higher up the org chart and with pointy hair, is more likely to give in to this stuff if its in a book, its got a happy buzzword-laced presentation, its very slick looking and promises to make things better. The guys in the trenches will adapt, anyway, so better to have some change than have the Dilbert mindset propogated for another generation.
Re:What the hell?? (Score:2)
Re:Sounding boards (Score:2)
If it doesn't feel good, you're not doing it right.
The person not at the keyboard should be coming up with ideas, constantly (certainly often enough to stave off boredom). If he or she can't communicate them, he or she says, "Let me drive." Pairs change "drivers" frequently, and should.
I see paired programming as fairly wasteful of my time.
See http://members.aol.com/humansandt/papers/pairprog
Then again, I'm prone to minimal laziness in my work.
"The three principle virtues of a programmer are Laziness, Impatience, and Hubris. See the Camel Book for why."
Re:P. J. Plauger (Score:2)
This happened back in the 1970s, and was written up in Constantine on Peopleware. (See also "Strengthening the Case for Pair-Programming" [utah.edu] (Google text version [google.com]).
Re:the zone (Score:2)
Two people working together in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don't check e-mail messages or favorite Web pages; they don't waste each others time.
Two people working together will have their shared time treated by others as more valuable. If I'm sitting at my computer, or just staring into space (thinking hard!), no one will think twice about interrupting me. On the other hand, if I'm busily working with someone, anyone who needs me will interrupt me briefly if at all.
Put a less experienced person together with a more experienced person, and the former will be more likely to stretch. Instead of sticking to familiar, comfortable tools and techniques, he or she will try things he or she only knows a little about, ask dumb questions
Put two people together, and you'll get more than twice as many ways to solve a problem. Each person will have his or her own ideas (there'll be some overlap), plus some half-baked ideas he or she wouldn't normally think hard about, plus the completed ideas of the other person, plus ideas sparked by their other person's, plus
One of the tricks of people working with each other is giving them an opportunity to learn how to work with each other. Programming In Pairs supports that better than trust falls or high ropes (which still have their uses, too).
Re:/. quality going down? (Score:2)
We should regress enough to be ready for a Katz essay on XP by midnight or so.
--
Re:Actually, it's completely different. (Score:2)
Your next bit...
Open source doesn't seem to work any better than closed...
I don't know how you made this assessment... Open source is not a panacea, but if you are actually relying on any code, its nice to have one of two things:
a) The code.
b) Someone to blame. Presumably they have the code.
Unfortunately, b) no longer works. It is now taken as read that software breaks, so it is hard to get a court to assign any damages when it does. So a) is better than nothing.
Almost everytime I use a closed source system, there is something about it that is broken. I want to fix it, but I can't. With an open source system, it can be fixed. To me, this does seem to lead to open source working better in the limit...
Of course there are a lot of useful proprietary programs out there. There are a lot of useful open ones too. And as time goes on, it seems like the number of proprietary ones that have no open equivalent is decreasing.
Re the money thing. Economic trends are dictated by what is better for consumers, not producers. The consumers choose where to spend the money...or not. If there is no need to spend money, it won't get spent. You can finish that thought.
Sounding boards (Score:2)
I agree that I find it infinitely more valuable to simply have someone available that I can constantly use for a sounding board. So long as I have that resource available and I can use it freely, I see paired programming as fairly wasteful of my time. Then again, I'm prone to minimal laziness in my work unlike one of the slackers interviewed in the CNET article.
My experiances (Score:2)
Ive found that design flaws are found much more quickly and often when 2 or 3 people sit around and create the solution as a group than if one person devises the solution alone and then brings it to the rest of the group to review.
I think that the reason may be that when comming up with a solution everyone is interested and actively thinking, while code reviews are boring and it's harder to be as attentive and alert to whats going on, so people let things slip. Another factor may be that the all the coders feel equal responsibility, in addition to desire, to come up with the solution, while in a code review, they naturaly (but unbenificially) place most the responcibility on the original coder.
On the downside, doing this requires you to be able to get along with your co-workers much better because you are around them more. You have to hove the patientce to explain your ideas to someone who doesn't understand them, and you have to let your ideas die in favor of someone else's. For this to work best you will disagree with you coworker and will have to beable to egolessly find ways to choose the best solution. These "negative" parts of the process are a big part of what makes it work: If you have work with someone that thinks simular to you it will be able to explain things easier and won't argue as much but you will also tent to make the same mistakes.
my two cents
Re:P. J. Plauger (Score:2)
This speeds things up by sharply reducing the amount of time you spend tracking bugs down. It also allows you to program with confidence, something few of us can do. You can break out of the "I hope I don't break this" mentality to a "Let's see if this works" mentality. The latter is a lot faster, as you're not worried about stepping on land mines.
Re:Very Misleading Article (Score:2)
Re:Common sense mixed with silly ideas (Score:2)
No, there's no "test plan" per se. You have a set of tests that you run whenever anything is changed, and especially before checking in any code. If you use makefiles, all you need to do is type "make test" or "make check" and voila! you've verified your changes. Especially when you've got changes needed and deadlines looming, it give tremendous payoff to be able to run the unit tests and be sure that you've not broken anything in your mad dash to update. After a while, you can't afford not to test.
Years ago I'd been in companies where we did this sort of testing, and it was always found to help productivity and quality quite a lot. Then later when I was at a company where we tried actual "XP", we saw the same quality and productivity benefits. Have you done so, or are you just dismissing a technique without checking it?
It's true that writing code takes man-hours. But some of the best code is that which is thought about and not just blindly "monkey-typed" at the keyboard. As they say in the carpentry field "Measure twice, cut once". Now if you put two people on just key-entry, then yes you loose. However, it's not just that. You have two people combining coding, design review, code review and project discussion all into the same block of time. That's where the payoff really starts to come in. The same reasoning that reactively says you can't put two people working on the same machine and keep productivity is similar to the reasoning of doubling the bodies on a project in trouble near the end to gain productivity...
You've mention scenarios that you "see", but that seems to be purely conjecture. On the other hand I've seen these principals put into practice and have seen them work. When you start to combine the programmers in the way espoused by XP, you end up with a gestalt effect where the sum of the whole is more than the sum of the parts.
Not at all. Balkanization is.
And that is balkanization at it's best (or worst). That "my code" "my name" mentality is the whole point. Or rather, avoiding it is. If instead of "my code" you think of it as "the teams code", then you get more away from the warring little fiefdoms and more into better code. Use source control every morning to see what everybody else did the day before. Whenever you find a problem, just fix it. Of course, try to bounce it off the last people to touch that area. And count on them watching everything you do also. There should be no more of the blame-game, and "well, my code is fine, it's Jim's that broke everything". Instead, it should be "our code is broken, let me see what I can do to help".
And also often just keeping in mind the thought that others will be looking over everything you write will help keep you from doing those 'dirty' little shortcuts that we are all tempted to take.
BTW, in the case you mention, part of what you checked in should have been your unit tests. So during testing when that person started to re-write what you did, it would be quite easy to get flagged the minute he broke anything. And better yet, you'd have had a complete audit trail of the performance (since that should have been some of your unit testing) and whether performance improved, degraded or stayed about the same.
Re:Common sense mixed with silly ideas (Score:2)
If that quote is accurate, then I'd say Lyle Hayhurst simply lacks self-discipline. Every bad habit he mentions is likely to catch up with him sooner or later. Which is better?
#1 is obviously the worst case. #2 and #3 - standard methodology and XP respectively - are both improvements, and #4 is the best of all.
Is #3 better than #2? Maybe, maybe not. On the one hand, it avoids the necessity of going back and doing it again. On the other hand, think about which one helps programmers develop to #4. Getting caught in a code review and having to redo your work can be painful, but often the painful lessons are the ones best learned. I don't see that happening with #3. What I see happening instead is programmers relying on their partners to act as conscience instead of having a conscience of their own, "putting things past" less competent partners whenever they can, and generally not learning the lessons that help them get to #4.
BTW, this is only one example of how XP depends on programmers being of near-equal ability. Unfortunately, that just isn't the case in most of real life.
Re:Common sense mixed with silly ideas (Score:2)
Ideally, yes, but reality does not always live up to our ideals. Let me guess, though: if the pair programming doesn't work the way we're told it should, then it's not really XP, right?
Yes, that's a big benefit, but one not unique to pair programming. Before XP even existed, I once took a three-week vacation right in the middle of "crunch time", leaving a very complex piece of software (the central decision-making component of a high-availability clustering product) in a colleague's hands. How was I able to do this? It's simple. The component was sufficiently documented, commented, and accompanied by unit tests that the colleague was able to understand it, and none of that had squat to do with XP. It was just common sense and professionalism.
If we want to evaluate XP's merits vis a vis other methodologies, we need to consider the ways in which it differs from other methodologies. All this crap about "turning the dial to ten" and applying practices that were known twenty years ago to be beneficial gets us absolutely nowhere. The only aspects of XP that seem to be actual parts rather than prerequisites, and that are not already common knowledge, seem to be:
So far, the arguments and evidence contrary to the XP approach in each of these areas seem at least as compelling as the arguments in favor. For example, the recognized goodness of modular decomposition is hard to reconcile with XP's attitude toward code ownership. XP's focus on short cycle times and refactoring, taking focus *away* from trying (trying, mind you) to get it right the first time, directly contradicts a huge body of evidence about what works and what doesn't on most types of projects. Yes, you should always plan to throw away the first version, but that doesn't mean it's even better to plan on throwing away the first seven or eight. I could go on, but I hope you see the point.
Many reasonable but negative comments and observations have been made about XP here. The answers from the XP proponents have so far been more evasive than convincing, mostly consisting of either "is so!" or "do all of this and magic will happen". Some of us don't believe in magic, and would prefer an actual explanation of how and why a reasonable person might expect practices that fly in the face of decades of software-engineering knowledge to work for non-toy projects.
Re:Common sense mixed with silly ideas (Score:2)
OTOH, if you have *inexperienced*, but good programmers, having them tag-team with a more seasoned guy is gonna do them both a world of good --the fresh guy will learn, the older will have a sanity check and an alternative idea/design source.
XP is way more than pair programming . . . (Score:2)
Pair programming, combined with group ownership of code, combined with incremental design, combined with constant unit testing (writing tests hand-and-hand with code), combined with constant refactoring, combined with a 40-hour work week (really), and a host of other practices that, working together, seem to make a difference in significant development projects.
There is a wonderful series of books on this subject, authored by Kent Beck and others. You can find more at this web site [extremeprogramming.org].
Re:Not pair programming (Score:2)
In both my experience and in Beck's book, that's not the case. Pair programming supports many of the other practices, especially collective code ownership, good unit tests, readable code, and continuous refactoring.
As with any of these practices, you can do without them and still develop. But over and over, Beck makes the point that these practices are synergistic; because they support one another, the point of XP is to use them all together.
Re:The one part of XP I don't buy... (Score:2)
Have you tried it? There are a lot of things that seem ridiculous until you get comfortable with them. True story: a couple of my college friends, a long-time couple, told me that they had tried sex once and decided they didn't like it. It was too weird.
It would drive me nutz - there would be constant conflict over which Slashdot articles to look at while goofing off...
Yeah, it does cut down on goofing off. On the other hand, if you follow the 40-hour week practice, then there isn't a lot of time for (or need for) goofing off at work. You get to do it at home or after hours.
And you only do pair programming while actually programming; if you're researching, reading, having lunch, or doing email, you split up to do that. It's only the coding that gets done in pairs.
So try it! If it seems weird, try it for a little bit at a time, but give it a fair shake. Everybody already knows that talking a design over is a big help; the same is true when coding, especially if you're following the other related XP practices.
Re:Common sense mixed with silly ideas (Score:2)
Have you noticed that most of the people saying that pair programming will never work haven't tried it?
I have tried it. It works. A lot of other people have tried it. Most of them say it works. Whether they are a junior programmer, an average guy, or a god among men, people say it works. I have only used it with programmers less experienced than me, and I would happily do pair programming again; I feel that both I and the project benefitted.
Maybe you should just set your questions aside and try it, saving all of us from explaining each and every tiny detail?
Re:Common sense mixed with silly ideas (Score:2)
Unit testing verifies that the output of blocks of code is good given certain inputs. However elegant your code is, it's never so fantabulous as to redefine "good", "working", or "error". Unit tests are the concrete embodiment of the definitions of terms like that.
Of course, I still don't write all of my unit tests first. But if you don't write any of them first, then you tend to write tests to match the current code, rather than making the unit tests match the intention of the code.
Note that "writing your tests first" doesn't mean spending Monday morning writing tests and the rest of the week coding. For me, I generally design an object's API and write a starter set of unit tests at the same time. I then pick a method, write some more unit tests for the method, then code the method. While coding the method, I'll think of other tests that could be useful, so I'll jump off and write those, too. The point is that you try to write the tests before you implement the things that are being tested.
The same thing applies to hunting bugs. If you have a bug, you first write a unit test that exercises the bug. Then you fix the bug. That way the bug will never come back, not ever.
Re:Question... (Score:2)
I'm assuming that the "stuff" in "stuff that matters" is a vague generality which encompasses pretty much everything. Extreme programming is a member of the set of pretty much everything.
Re:Why Extreme Programming is Extreme (Score:2)
Code reviews and the zone (Score:2)
I do too, I must admit, but the code that I do write "in the zone" tends to be the most in need of a code review when I'm done.
And really, that's all pair programming is. It's a very tight code review loop. We all know code reviews are good, so let's do it all the time, even while coding. Pair programming is code review taken to extreme. Everything in "extreme programming" is actually stuff we already know is good taken to extremes, hence the name.
Other XP articles (Score:2)
Also, a good overview of XP can be found on developerWorks [ibm.com].
I work for RoleModel Software [rolemodelsoft.com] (on the Organon Teknika Project mentioned in the InfoWeek article) with the guys who wrote the developerWorks article. I'll try to answer any questions anybody might have, and I'm sure Chris and Roy will too (their emails are in the article).
Coed Naked Extreme Programming (Score:2)
Been there, Done That (Score:2)
I read somewhere that "The Zone" takes on average, 15 minutes to get in to (Someone actually MEASURED it!) and, as you said, can be broken out of in just under a second.
Yanno... (Score:2)
That's Standard Hype (Score:2)
The level headed person will realize that there's no magic bullet. The machine can not think for you, so if you put an idiot at the machine, no amount of software's going to make him useful. No amount of extreme programming or UML or any of that crap will help you if your management's poor (And it takes only 1 bad manager to destroy a project.) No amount of visual design tools will help your programmer if he doesn't have formal training and a certain level of innate skill.
Given good managers (Who can get good requirements) and good programmers, all this stuff CAN help you be more productive. But in any case you're going to be more productive than a project with requirements that change every week, bad managers, and programmers who couldn't find their ass with both hands (Which is why Hannibal will never ship, and when they try to blame Linux for their failure, I'll be right there, waiting for them. You know who you are. You've been warned.) Unfortunately in this industry, the latter project is far too common.
Re:Very Misleading Article (Score:2)
I've never used XP, but I've glanced at some of their books. Part of XP focuses on the problems you mentioned. For example, XP advocates using the 3x5 index card as the unit of customer requirements - each requirement is written on one card. By arranging the cards in a rectangular grid, it's possible to communicate the time/people/requirements tradeoff graphically. The height of the grid is the number of programmers. The width of the grid is the number of weeks needed. (Yes, it doesn't illustrate mythical-man-month well) While this isn't a silver bullet, it could help bridge the gap between programmers and customers/management.
XP is only partially about programming - it's largely about interfacing with the customer.
Re:Actually, it's completely different. (Score:2)
"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."
"Nobody is making any real money"? Only governments make real money legally.
"Makes less money"? For who? Much of Open Source and Free Software simply gets the job done, most is free of charge and you can fix whatever bugs or extentions you need yourself if it's critical. I'm afraid that you have been caught in the stupid illusion that money has value. It has not, it's just one of many representatives of value/energy. I and many others knew this at 7, time to grow up.
The real incentive to share your work is so that everybody can share their work and benefit from this process collectively. The "money-making" business that IT supposedly has been doing the last year has not really put that much value in society. Just hype, illusions, further restrictions and exploitation on people. Hint: A rise in economy has nothing to do with real value being added as much as it has to do with people's expectations on future growth.
But of course, if you believe money has value you may disagree with my value-system. Then it's better to agree that we disagree.
- Steeltoe
Re:the zone (Score:2)
Pair Computing (Score:2)
If companies can afford two proggers at one computer, the return on their investment will likely be substantial.
XP and ADHD (Score:2)
Re:I don't know about you, but... (Score:2)
More buzzwords! (Score:2)
Let's have Open Source Object-Oriented Extreme Programming!
--
Trust issues (Score:2)
1) Cost Even though the "all bugs are shallow under many eyes" argument holds true, try convincing management that two programmers working on the same thing is cost-effective.
2) Trust I'll be the first to admit it, but the concept of having someone hanging over your shoulder while you code is rather disconcerting. There has to be an understanding that mistakes will be made, and not all coders are good at all things. Anything involving scary mathematics and optimized algorithm design, keep me the hell away from that. Object oriented analysis and design? Now we're talking.
3) Inertia Everyone remembers "a body in motion," but most forget "a body a rest." In the business world this is also known as: "We've always done it this way." As much as we would like to believe everyone is on the cutting edge, a lot of folks get nervous around sharp objects. There is significant resistance to change in a lot of established organizations.
Still, XP has a lot of promise, but I've seen the whole "new paradigm programming methodology" upset thing before. I like parts of it, others I'm skeptical and concerned about (ie: how well does it scale?).
Time will tell.
Re:Sounding boards (Score:2)
Whenever I've done this, we actually work on two different projects (on two machines) at the same time. We'll both code for until we hit a bump or get something finished, etc., then we'll look over the other person's code.
What is this 'Extreme Programming'? (Score:2)
http://slashdot.org/books/00/12/29/1653211.shtml [slashdot.org]
http://slashdot.org/books/01/01/30/044210.shtml [slashdot.org]
There are actually 5 books so far; do a search for Extreme Programming on Amazon. I've only read 2, since 5 is an awful lot for any programming philosophy.
Well, to sum up all this: yes, the 2 coder approach can work quite well. It seems like work, but try it on some real stuff-- it's generally more productive than 2 coders working separately, especially when you count bug fix and QA time.
Another Extreme Programming philosophy is test often, and one popular way to do that is using JUnit tests [junit.org].
We've been using the JUnit tests with great success. We haven't been doing as much pair programming, though I'm not sure why-- whenever we do it it kicks a lot of ass.
I'm sure someone here can give a better summary-- one or two of the authors of some of the Extreme books post occasionally. I'd be rather surprised if any coders here hadn't heard what I just posted above-- if you haven't, what rock have you been hiding under?
Re:What the hell?? (Score:2)
Right after XTREME (note the absence of the "E", in order to emphisize the coolness factor) Paint Drying!
--
Very Misleading Article (Score:2)
Hogwash, I say! Using XP will not solve the problems if the project is poorly managed, or there are no clear requirements. These are some of the problems that cause productivity to fall, not the method of programming!
While I think that XP can be beneficial, the article makes you think that solitary programming is inefficient and counterproductive by nature. This can't be farther from the truth! If a programmer is disciplined (and well-trained), they can be just as productive as the xp programmers. All this, and only charging one programmer's rate to the customer to boot!
A final thought: If you put two bad programmers together for xp, what assurances do you have that they will produce good code at all, not to mention more quickly than one good programmer? I can see it now:
Bad Programmer #1: I'm creating a global variable for the user's password, okay?
Bad Programmer #2: Sounds okay to me, we should also put all his personal info in global variables too!
Re:Extreme Programming == Insult (Score:2)
Any attempt to make it more "formal" and "rigid" will take the fun out of it...
You may call it "formal," "rigid," and "no fun," but I call it "being professional."
IMHO, software companies have been following the "pay the geeks, let'em hack" philosophy of software project management for too long. It's time we brought some formality into the process. Now, whether this Extreme Programming is the answer is a separate question. I'm as not sure of that.
But if you want to hack for fun, I say do it at home.
--
What if your partner is an asshole? (Score:2)
Granted, that is partially tongue-in-cheeck, but it does raise the question of how do you choose a pair? I prefer to enscript all of my source (even if it fills a 3-ring binder), take a few days off, and skim the code. That's a great exercise for getting a feel for the bigger picture I'm creating.
Although the book does sound interesting, the article referenced is pretty lame.
---
Re:yes and no (Score:2)
Steven
Re:I find that pair programming works best... (Score:2)
Steven
RoleModel SofTware (Score:2)
RoleModel SofTware [rolemodelsoft.com] has been doing XP for a while, and writing a lot about it.
In addition to all of their stuff about their experience with XP, be sure to read their paper about Apprenticeship as an educational method. [rolemodelsoft.com].
I dislike that you have to be a Christian to work for RoleModel SofTware, but I like that they stand by their ethical values. I'd love to work for a company that had a pervading "ethics first" principal.
Been there. Done that. (Score:2)
The team coding thing will work, but I don't know if two people stuck together in front of the same computer 100% of the time is the right formula. A lot of programming is getting down in code the ideas you've brainstormed. Sometimes that can be tedious for the person not at the keyboard. I guess I'd advocate team programming but on a staggered shift.
Cheers!
My Experiences with eXtreme Programming (Score:2)
Deja Vu -- Not what I expected... (Score:2)
Last time somebody started expounding on extreme programming, I closed my eyes and listened. Where I was whisked to was the land of Engineering Management 410, with a grey-haired old codger at the front of the room berating us about our project plans. It was also slightly reminescent of a Project Scheduling and Cost Control seminar.
This appears to me to be a simple application of the resource-time-quality triangle, coupled with some basics ripped out of Rapid Protoype Delivery methods and the old "Egoless Programming" scheme.
Just think. It only took thirty years to get popular in microcomputer-land while the rest of us have been using it (where appropriate and possible) for years...
Re: (Score:2)
The one part of XP I don't buy... (Score:2)
More seriously, I find (from working in a couple places) that frequent and vigorous code reviews coupled with a reasonable coding standard fill the "constant QA" gap rather well - no need to set two employees to cramping each other's style.
OK,
- B
--
Re:Other interesting parts of XP (Score:2)
Re:The one part of XP I don't buy... (Score:2)
Re:Extreme Programming == Insult (Score:2)
Re:Trust issues (Score:2)
Persuading programmers that they can work with someone peering over their shoulder is a bigger problem...
Re:Amen, brother! (Score:2)
Re:Common sense mixed with silly ideas (Score:2)
Re:I've said it before (Score:2)
How I handle that: write a little bit of a program. Get it working so I can show it to them. Find out what they want to change, or what they want to add next. Repeat until they're satisfied or the big boss comes and tells them they're sucking up too much of my time.
I just never knew that was called "Extreme Programming"
Re:Common sense mixed with silly ideas (Score:2)
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.
I suppose that depends on what we mean by bad programmers. Sometimes, it's a skill issue, in which case, you're right. But more often than not, it's that american work ethic. In those cases, I think they're more likely to collaborate on which site to surf to next.
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!
A good programmer's mistakes are caught by the compiler, by sanity checks, asserting values, checking return codes, and unit testing. Even then, some bugs will slip through. But putting a good programmer and a not-so-good programmer, I think, is not likely to improve this situation since, in the majority of cases, the poor programmer may not be together enough to catch the mistakes of the good programmer. But this isn't really about programming errors. This is more about good design. And any good programmer should be able to produce a good design all by himself.
Two good programmers could inspire themselves and develop genius and elegant ideas that one of them would never come up with.
Which can be done at the design stage, right? Large projects are usually designed in groups before-hand. After that, it's only the small pieces, the details, that need to be designed. Those pieces should be trivial for a good (not even great) programmer. If they're not, they were discussed in the design meeting, right?
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.
This is simply not reality. Writing code is like building military aircraft. 50% of the cost goes to the last 5% of the performance. Do you really want to cut your productivity in half to get that extra 5% before unit testing? When unit testing is likely to flush out most of the remaining 5% anyway? It looks to me like you're cutting productivity in half (effectivly doubling the required man-hours) in the hopes of more than making up the difference in testing. I just don't see the return on the investment.
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.
If it were my job to teach him, I would teach him. If it's my job to hit deadlines, I'm going to hit deadlines, while trying to remove anything that slows me down. Training employees should be completely separate from project tasks.
I can't see any good scenarios, for me, from pair programming. I can see how the less skilled/experienced programmer gets trained. I can see how the manager got his cheap employee trained without having to pay for training. But I also see how I had to slow down to explain what I'm doing to another person. And to justify what I know to be a good design to begin with. And possibly to put up with an arguement from another employee who doesn't quite know what he's doing and hasn't learned office politics yet. Maybe it would work for some people in some cases, but I can see it causing a lot more problems than it solves.
Re:Common sense mixed with silly ideas (Score:2)
Customer always available: Actually, that's often possible. And once you've delivered one project like that, it's much much easier to get business buy-in to doing it again.
Sometimes they're there, sometimes they're not. And in many cases, their presence doesn't help anyway.
Unit test first : It's possible more often than not.
I'm not saying unit testing is bad. It's vital. I'm saying that it's not always possible to write the test plan/code before the code is written. After all, we don't know exactly how all that elegant pair programmed code is going to flow, right?
Collective code ownership
Once again, real programmers test their code as they write it, then unit test, then assembly test. If someone makes a change in the code, that change should be tested and the unit tests run again. This is different from everyone owning the code. I'm not sure that that's really a good or a bad thing. But I do know that everyone who uses source code control already does this.
Pair programming: Maybe your ego prevents you working with someone. Most intelligent people seem to manage fine.
The issue is not that I'm unwilling to work with other people. It's that I'm unwilling to discuss every single line of code with a less experienced programmer sitting next to me while I'm writing it. Or put up with the excruciating experience of watching someone else type. I type faster that I write and think faster than I talk. Slowing down for another programmer would interrupt the free flow of thoughts and ideas. It's disruptive and annoying. I'd rather delegate a piece of the project to that junior programmer and examine it when they're done.
Please, don't go dissing techniques you haven't yet tried.
Actually, they're considering using this where I'm working now. So I've done some research into this.
I've been trying them, and there are flaws, and I'm publicising them within my company. But there are also major benefits, and I'm sharing those.
You're right, there are flaws and benefits. And as far as I can tell, the flaws are many, and the benefits are things that many people have been doing in IT for many years.
I congratulate you on your good testing. I sounds like it serves you well. I also suspect that the entire testing system you have could have been created without paying a lick of attention to XP.
Re:Common sense mixed with silly ideas (Score:2)
> If you put two people on one task, unless that task is done at least twice as fast, you lose.
Bzzzt. Wrong. Raw construction does not account for the majority of time during project development. (We are talking about software development, not l33t hacking or informal collabrative projects, right?)
> And there's no guarantee that you'll get better code.
And there's no guarantee that the moon will stay where it is for the next year. What kind of statement is that? Clearly people are saying that you do get better code.
> Collective code ownership = chaos.
No one has 'ownership' of their code for very long, at least not in any medium sized or larger concern. So this isn't a 'problem' to begin with. You're problem isn't an XP problem, it's a change control team or management issue.
> 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?
This would be a fair comment if XP was just coming out of the hands of a pair of l33t buddies. But it's not. It's been around for a while now. If you want to stand around ridiculing every bus that comes by just for the sake of it, I guess that's you're call. Instead we could really use an unbiased analytical comparison of what XP claims to encompass against what one would have to do to equal it. (Pair programming plus... what?)
Been using it for a bit now (Score:2)
As far as the "this will slow me down and I won't get to surf as much" argument: we have the advantage of actually having test code and constant code inspection, two things that I've seen many projects missing.
Toned-down pair coding: Code review. (Score:3)
The results are less dramatic than those advertised here, but still worthwhile for something that lasts no longer than a standard project meeting.
Re:Common sense mixed with silly ideas (Score:3)
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
It requires good programmers (Score:3)
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.
Actually, it's completely different. (Score:3)
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.
Not pair programming (Score:3)
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.
Doctor Dobbs has seen it all (Score:3)
DDJ columnist Verity Stob reports her experience with XP here. [ddj.com] Check it out -- it's an interesting read. While you are at it, you could also read her dig at Slashdot [ddj.com] in this month's column.
yes and no (Score:3)
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
Burn out? (Score:3)
Common sense mixed with silly ideas (Score:3)
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?
Re:Extreme Programming == Insult (Score:4)
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 (Score:4)
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 (Score:4)
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 (Score:4)
Aside from Quake though, it's pretty much useless.
the zone (Score:4)
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:Burn out? (Score:4)
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?? (Score:5)
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 (Score:5)
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 (Score:5)
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? (Score:5)
X-Coding will be shown at 9:00pm, right after X-DataEntry and X-MSCE-Testing.
Damn it. (Score:5)
Oh well.
Re:the zone (Score:5)
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:Common sense mixed with silly ideas (Score:5)
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... (Score:5)
Trolls throughout history: