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.
I guess it's that EP-3 the Chinese have captured.
If you are not familiar with the concept of extreme programming, please reframe from making grossly inaccurate comments. It is clear you don't understand that extreme programming (XP) is about software engineering, has nothing to do with multiprocessor systems, and is noted as not being aimed at large projects (programming in the large scale). I have to question the poor quality of editorship that the slashdot crew are exhibiting. I know people make mistakes, but fight the JonKatz affliction of talking about stuff you know nothing about. You sound like the people you make fun of (PR/marketing/management).
Earlier today we saw a more advanced article about XP, a book review which explains how to put XP into practice. Sadly, the editor of the article did not understand what XP was in the first place, so his comments for the review were rather inappropriate. /.
/. had no banner ads and no comment accounts, such occurrences were rare at worst.
Now we see an introductory story about XP. Although this article, standing alone, would be OK, it is rather redundant in the context. While this time, the editor had a grasp of the topic, he seemed to have forgotten to check the current articles on
Of course such things happened before, but in the "old times" where
yep, rright here. they don't do her justice, tho. check out cnbc in the am, she's on early. mmmmmmmmm. liz is the hottie. i think the shot of her in the purple dress shows her nice large tits to advantage. i'd pay big, and i mean big money for a dte with liz!
"shop smart:shop s-mart" ash
Ward Cunningham, a well respected developer and maintainer / creator of the Wiki web (c2.com/cgi/wiki) actually wrote a position paper at OOPSLA 2000 detailing how XP is "genius friendly". Look at http://oopsla.acm.org ..
As for the customer being available, XP doesn't necessarily require it, but it's quite clear that you'll get better quality software if they are available. It's about tradeoffs. You want quality software? Sit with your customers, have one dedicated to sitting near your team for ad hoc q&a sessions. You want long turnaround times and frustrating misunderstandings? Talk through documents / weekly meetings.
-Stu
I agree with you, I use the same excuse too.. "well, everyone else sucks". Really, they do.
But what about teams that have skilled developers, a good leader, but fail out of the business pressuring them to do shoddy work (due to waterfall-esque thinking, etc.) It's common. XP provides a process out of this trap.
-Stu
"It's a neat idea, a great mental exercise, but I doubt that it will make it past the trendy self-help phase into an accepted way to run a programming department....it will be a long time before the traditional caffeine / overtime / don't-touch-my-code programming paradigm goes away"
I could sum this up as
"mediocrity is easy".
How is pair programming (assuming you aim to do it 75% of the time, a realistic goal) implausible? Sure, it's not easy to just flip a switch and get everyone's egos in sync. It takes a certain kind of mentality to do and some cowboys just don't have it, (but arguably they don't have the skills to be cowboys either..)
Jerry Weinberg once said in Psychology of Computer Programming that "the best coders enjoy other people looking at their code, always hoping to learn new tricks or ways to improve their technique. the worst hide their code. and, typicaly, the best get better, and the worst get poorer..."
Isn't it true that if you don't subject yourself to constant review / incremental improvement, your 31337 skills are going to be less honed?
-Stu
regarding short procedures / long names.. it was definitely part of the XP philosophy which sort of grew out of the smalltalk philosophy. it fits into the Refactoring idea that you should probably write an explaining method name before you write a comment .. or you should apply "extract method" when your methods are over 20 lines.
http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign
-Stu
Myself and a cow-orker needed to write a web-based survey in perl, after one previously written bombed out, and didn't provide enough reporting information- We both sat down, and planned it out, and then along the way, one would ask the other, "Would it be better do to it this way" -- and in the end, we had a very nice survey application I *would* have released under GPL, but the company owned it. (I have since left the company, and the company went belly up)
da w00t.
da w00t. mtfnpy?
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.
You got it all wrong. Pair programming is not about someone watching over your shoulder or nagging about your mistakes. It's co-operation.
The fellow does not watch over your shoulder. He sits next to you and his purpose is not to watch out for the bugs you make (although he does it automatically) but to give his thoughts about the design and share his knowledge. Also the fact that someone tells you immediately that you made a bug (because you assumed that the function/method never returns null) is very rewarding when you consider the amount of work you have to do to find the bug later.
Everyone I know who have tried pair programming say that two mediocre programmers programming in pair always produce better code than one good programmer coding alone.
Antti S. Brax - Old school - http://www.iki.fi/asb/
As a (good) "programmer" I find this sort of software dogma insulting (same w/ patterns.) Coding is more like art than a science. Any attempt to make it more "formal" and "rigid" will take the fun out of it, and will cause the brilliant people to leave in disgust, only to be replaced by mindless drones who employ such mind-numbing practices as "Extreme" (w00000!) programming.
First of all realize that the pair works together, they are not trying to get something past the other.
The other big benefit of pair programming is that two people know the code. So you can go on vacation and not worry that you'll get called to fix production problems...
...richie - It is a good day to code.
Welcome to "Real Life" (tm). And in what engineering field is it desirable to have apathetic and unskilled workers, and a stupid team leader?
Reminds me of what John Glenn said, when asked what it felt like to ride the rocket into space. He said: "How would you feel to be sitting of top of a rocket built by the lowest bidder on a goverment contract?"
...richie - It is a good day to code.
However, when an application is complex enough it maybe simpler to modify the source code rather than a configuration file. Often the configuration will be expressed is a custom language designed by the developer, rather than in a well understood programming language.
Don't believe me? Ever tried to configure "sendmail"? :-)
...richie - It is a good day to code.
There are several sendmail replacements that are easier to manage an more secure, eg. qmail.
But contrast sendmail's config file with the Linux kenerl modules. Rather than designing a way to generically deal with any possible device and then inventing a config language to describe it, an interface is defined and people can extend the kernel by writing modules in C.
One of the things that XP advocates is that each project include a suite automated of unit tests so that you can be fairly sure that when you make a change you don't break things.
You say in XP environment, this is even more nasty, as the code isn't logically complete. This is not true. The delivered application is a complete running program. Just because it may not implement all the required functionality does not mean it's logically incomplete. No running program implements all it's possible requirements, so by your argument no running program is logically complete.
...richie - It is a good day to code.
I don't know, "40HourWorkWeekSoYouCanHaveALifeProgramming" seems extremely catchy to me.
And don't pretend you work like you're possesed every hour on the clock, either. Or you wouldn't be reading this right now!
Send your friends messages of love at fuck-you.org
You don't. Today, Charly's looking over your shoulder; tomorrow, you'll be looking over Oliver's. That way, knowledge of the whole project is shared among the team. Oh, and everybody gets to have a go on the keys ;-) And in case you're wondering how somebody is going to pick up and run with the code you wrote yesterday, that's why you code the unit tests first. They help to define what the code should do.
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
from the "sounds-vaguely familiar department"
Thanks for the laugh Taco
A master and an apprentice.
I guess you missed the XP idea, the XP idea is thay you and me as good programers could develop better software in a way that is fun to work in. Not HAVING to fill into the rigid hard wall that defines all other programing modela I have seen i real work. While we still could deliver something that works. For an example if i work two weeks on a problem, (being a hard one). Does all the unit testing, it works, it gets delivers bu the deadline, i enters verification. Then one or two or maybe four months later. I get a bug report on that old code, it's not fun to go back and make a minor change. And maybe that it was a minor special case that got a in the test. I didn't see it that and it took me a week to get back into that part of the code and twwek the unittest so that I could reproduce the error with in a controlled enviroment. If I have to that to many times I get borde and don't think the project is fun any more, then I leave, and soon there are only the ones that can't leave that has to fix all the uppcoming bugs. It never gets good and you can't be prod that you where in that project.
On the other end, in XP, my buddy whould have asked me why does you use there. I have to look at it, and finds the problem at once. I'm also pretty shure that when i "make test" everything works.
I does understand your worries, I first fouthe the same, and coding still is an art. Thats why XP could work and other metods are hard to get result from.
XP is shortly, do whats gives good code and do it a loot!
I have done a loot of coding with Code Review, and I don't find that it works. I find that there are two main reasons for this.
One, it takes time. If you have reviews when a part of function of the code begins to get ready. (Actually there seldom are any idea before this.) There is a loto of code for the reviewes to look into, so they have to spend aloot of time to prepare and try to understand what the code is about. Then they tend to miss a loot as the time is limited.
Two, it usally comes down to a find over coding style. You have missindented that paragraph. Why dosn't you break the line there and so on. This usally while the "problems" remain. Reviews other don't like to complain when they don't understand the code, it could look as they are stupid on the meeting. And the code wither does always depend his way on the meeting. I did it right, (and I don't like to go back and fix those minor details, even if they are wrong.)
With the real pair programing you does the review all the timne and you get a possitive competision, and a nice feeling. It gets fun to code, you don't have to defend you self, you don't have to spend a loooong time trying to understand what the HEEELL is this.
When I've done this, the coding partner tended to function as an uber syntax/architecture/sanity checker, pointing out things that I may have missed, and trying to stay a step ahead of me.
It's fun. Why don't you try it some time?
I see a lot of people objecting to pair programming. As someone who learned 6502 assembly while coding with a friend on his VIC-20 after school, I can tell you that it works - bugs are caught early and often (usually before the compiler gets to see them), and the whole process is a lot more fun, in general. I was surprised to find out that many people simply can't code when somebody else is present in the same room. I actually find it more difficult to code when I don't have somebody I can explain things to while I'm working.
The part of XP that are most appealing to me are the iteration cycles: Essentially, the programming team takes a list of all possible improvements or features from the business side. The team then estimates how long each feature will take to implement. For example, creating a new look may take 3 weeks of pair programming. We convert the weeks into points (3 weeks may be worth 5 points), so that each feature gets a point value. We tell the business side that based on our past performance, we can finish 30 points in the next three week. Now, while the points of all the stories may add up to 100 or more points, they can only spend 30 points in a given three week iteration. At the end of the iteration, we do it all again.
"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. "
Uh.. surely that's called 'working on a team project', if you're not actually sitting at the same computer... and programmers working on both commercial and free software have been doing that for a *very* long time.
The 'pair programming' concept relies on the fact that both people are working on one computer together. As a result you brainstorm the solutions to problems quicker, and the person who isn't doing the typing spots a lot more of the bugs.
It's fundamentally dissimilar to working on the same project but in different places and at different times.
This wouldn't be a bad idea for the Slashdot crew...not only for Slashcode (which is generally a good hack) but for Slashdot itself. It works like this: every story must be read over by a pair of editors sitting at one terminal (or using one laptop). If one editor doesn't know what the hell the story is about, the other one can look at it and may have a better clue. Your compitency level in any category becomes the larger of both editors' levels.
There are advantages to this design: peer review (which formerly didn't exist at all), not as many displays of editorial cluelessness, faster updates, more eyes looking out for crap, and fewer redundant stories.
Of course, because both people will share one seat, it's impossible for both editors to write simultaneously. This could be a plus.
ObJectBridge (GPL'd Java ODMG) needs volunteers.
Finding God in a Dog
Not boss, coworker. And you trade the keyboard back and forth.
It works much better in real life than it sounds like it would.
Quite true. I've been applying some of the ideas from XP (it's hard to embrace all of it in within an existing corporate culture), and now think about not having the things that XP providers (tests to know your code works, resilence against changing requirements) as extremely risk.
XP is a strategy for dealing with real-world risks.
XP is an many ways the total opposite of "hacking". When is the last time you wrote unit tests and/or acceptance tests first (or at all) when hacking?
[if you're not going to take the time for architecture design]
This makes it sound like XP is about punting on architecture. That is far from true.
Just wanted to point a couple things:
"It may be remarked in passing that success is an ugly thing. Men are deceived by its false resemblences to merit."
You only code the functionality you need. Don't bother making something more abstract than you need at the moment. As your needs grow, you modify your code to handle the next cases, and occasionally clean up your code. This is the "refactoring" process that the article refers to.
It's interesting in that it runs counter to the way most of us are taught to program. We're told to make sure we consider how things could be used in the future so we don't code ourselves into a corner.
It would be interesting to know which method actually requires more work in the long term.
"It may be remarked in passing that success is an ugly thing. Men are deceived by its false resemblences to merit."
Extreme Programming may be the latest buzz word, but peer review is an established technique used throughout the fields of science and engineering. I agree with the previous poster - if you can't handle peer review, then I don't want to work on a project with you because I don't want my code to fail because of something you did in a hurry.
Notice that I didn't say constant peer review; I think the whole two-programmers-at-one-machine plan sounds nuts too, but I guess if you're not going to take the time for architecture design and coding standards up front, maybe it works. We generally do peer review on a module-by-module basis as they are completed, and if you've invested enough design time up front the reviews (and in fact the coding phase itself) are pretty straightforward and relatively painless. Bottom line, if your team is tasked with a project, then all of the code belongs to the team and the team gets a say in what you do and how you do it.
If anything I would say XP doesn't go far enough - if you're catching serious errors at the point of typing out the actual code, you're catching errors way too late in the process. But I guess you've got to start somewhere, so if XP stops the worst bleeding in your organization's development process, then I say go for it.
Your right to not believe: Americans United for Separation of Church and
It works better to have reviews in a smaller meeting with just the immediate peer group for the project. Sure, there may be 20 coders on the project but there are probably only 3 or 4 other people whom your modules interface with that need to be there. If there's more, just pick those with the time and expertise to really review the code properly and understand the implications of it. Plus the distraction level of a meeting rises sharply as you add more than 5 people (or at least it seems to me).
It also helps to issue a review agenda ahead of time, and have the reviewers look over the code ahead of time as well. That way if they see anything really dumb, they can talk to you one-on-one before the meeting about it, and when you get to the actual meeting they can just summarize quickly, you agree to implement "what we discussed yesterday", and everybody moves on with face saved.
You also have to have somebody at the review with mgmt power and/or sufficient expertise to be able to ultimately resolve all arguments about how things should work, if you can't reach a consensus among your peers. The worst thing you can do is just have a lot of criticism with no resolution. Good or bad, there has to be someone who provides resolution, even if it's just a plan to go back and rethink things.
Your right to not believe: Americans United for Separation of Church and
OK, a bit of hyperbole in fact. My point is that you should have little or no real heavy lifting to do by the time you're ready to start coding, so I'm not sure how actually having two people in front of a computer helps. At that point you should have module interface defined and understand the algorithms that you'll be using within them. It's really more of a detailed design stage after architecture but before coding.
Your right to not believe: Americans United for Separation of Church and
Pair programming *is* important. It assists collective code ownership, it helps junior developers by letting them watch senior developers work or by having senior developers make suggestions, it keeps developers honest, and it allows for real-time design discussions. Also, UML is not discredited IMHO, although the RUP is. With the proper modeling tools (such as the spectacular Together/J), UML diagrams are interchangeable with source code and are just another, more visually concise way of looking at the design structure of the application (as opposed to the logic). UML is a much better design-phase representation an object model than source code. Try printing out & taping to a wall (a) dozens of classes in source form and (b) a big UML diagram on a plotter, and see which works best.
Team programming is explicit in XP, and that goes beyond the usual open source non-methodology of CVS + majordomo. Tell pesky junior developers to shut up, to watch, to write questions down, and to email them to you later if you have to. That's a pretty selfish attitude from a team standpoint, but I could see that being a valid approach given an extreme situation (such as, you already answered those same questions yesterday, and the day before, and the boss won't fire the doofus).
In my experience, sometimes pair programming means 20 minutes of silence while one person rocks out and the other just watches and nods, or even one person struggling until the other says "dude, I know how to nail this, just let me drive for a couple of minutes."
I was on a fairly recent project that involved pretty much constant pair programming. It wasn't by choice; the assignment was to fix a particularly hairy and dense section of an application, and it was so badly written that we couldn't find any clean way to split the work between the two of us, so we pretty much had to work as a pair. It was amazing. I was definitely the more senior one - more experience, more familiarity with the language and runtime environment - but the other guy stunned me with his ability to skim a tangled loop construct and instantly spot what was wrong. He was also able to think about the larger process more quickly than I because he wasn't distracted with the mechanical process of build, test, check in, etc. In a normal situation I wouldn't have had any problems keeping up with this but this was somebody else's screwy development environment, and the way the code we were fixing was written by a madman. In a normal situation I would expect that pair programming benefits would be more along the lines of real-time QA and design reviews.
BTW, given the amount of positive sentiment about XP from actual developers (as opposed to methodology crazed academics), I'm surprised how many people are willing to reject it offhand. It's a pretty skinny book, and it's not hard to just try pair programming and see whether it works.
Another uninformed comment. Can't anyone be bothered to learn something about the topic they're attacking? Oh wait, I forgot I was on /.
I spoke with a guy last year who had worked at Amazon, and he said that some of their developers were citing XP as written justification for a lack of any methodology whatsoever. Just start coding shit up and hope for the best because it's too hard to plan, document, test, or coordinate team efforts. That is *not* what it's about. The most significant practice from my point of view is the very robust testing: going from defining features to defining test cases that prove feature completeness to writing test harnesses that test code for correctness to code that satisfies all of these tests. Hacking to me means making it up as you code, with simple tests afterwards to make sure it at least works in the obvious case.
Everybody seems to think that working in pairs means that you sit at the computer, and the other guy bothers you, so you can't get in the zone.
What if you're the one "riding", what's to stop you from getting in the zone? In fact, you have less to distract you since all you're doing is looking at and thinking about the code. No need to worry about tab stops, mouse wheelie scrolling, and curly brackets. Just what the code should be.
Users and developers are on equal footing but users don't get to decide on estimating how long it takes to implement something. Part of XP is the assertion that the different practices are distinct but that they definitely reinforce one another - take out pair programming and quality goes down. Take out refactoring and you're completely screwed; you can't design a process around incremental as-needed redesign (refactoring) to avoid a big design phase up front, and then remove design altogether.
These are doubts which are directly addressed in "Extreme Programming Explained" as well as numerous web sites... learn about the process before dismissing it as too idealistic.
Cost: this is a very valid point, pair programming is counterintuitive from a cost vs. productivity point of view. XP evangelists and would-be adopters need more ammo in the form of studies that show that pair programming works.
Trust: pair programming isn't about a smart guy driving and a not so smart guy watching, nor is it about you driving and a DMV instructor writing down all the mistakes you make. If you know how to use the development tools and the language you can drive perfectly well while the other developer brain-dumps code through your hands. Likewise, you can sit back and say "damn, that's some pretty clever shit right there" and learn from what you're seeing the other developer do.
Inertia: Making reasonably competent managers and other business people change is a matter of selling solutions to known problems (fewer bugs make it to QA; we start hitting our milestones) and business value (greater development capacity, more small releases mean you can see that things are or are not tracking to plan sooner) rather than the implementation plan for solutions (let's do more testing, let's have the same number of developers working on half as many issues at a time). Sometimes managers won't improve things because they are afraid, at which point it's hopeless and you should either quit or go over their head.
> 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.
Few of us can do? I wish some of my coworkers programmed with less confidence.
--
Sheesh, evil *and* a jerk. -- Jade
Hm... I have a hard time believing you actually read my comment. Find where I said good quality closed source was impossible... clearly its not.
There are also a lot of strange perl scripts floating around on freshmeat that no one should trust. The cost of evaluating one of these silly programs is far greater than the cost of reimplementation. I am talking about things where the cost of evaluation is outweighed by the cost of reimplementation. Eg an operating system, C compiler, mail server, etc etc.
What I said was that you get no *legally enforcable* guarantee that closed source software will even work at all. General opinion is that software will continually break, and if you trusted some software to do a job, it is your fault. Lots of *huge* software contracts are not fulfilled in any meaningful sense (look at eg EDS' history), and it is only very rarely the seller is held liable. In this atmosphere it makes practically no sense to choose a closed source alternative when an open one does the job, even less proficiently. You are just asking for pain needlessly. You are taking the risk that you will have to go to court and lose. Some people try to construe this as an advantage of closed source software: The "who do you sue" argument. This view takes no account of the actual likelyhood of winning a case. If you feel the need to pay someone, pay someone to make the improvements you want. The only time when closed software makes sense nowadays is when there is no open alternative.
So if you look at it from an economic perspective, a closed source solution has a huge risk attached - that it will not do the job, and your entire investment will be written off. An open source solution has a smaller risk - that it can not be modified within budget to do the job. For these reasons, I only choose a closed source solution when absolutely necessary.
Extreme programming's certainly interesting, but it's not the only alternative to the waterfall approach. People who are interested in XP might also want to look at Booch/Jacobsen/Rumbaugh Unified Software Development Process, which is described in a book of the same name (look at the big Addison-Wesley software engineering section at your local B&N for it and dozens of sorta-companion books).
Of course, XP has the advantage of sounding more glamorous and radical, which probably explains why it gets the press.
I admit, I see XP as a very effective means to publish many friendly books which geeks will buy voraciously resulting in big gains for the authors.
Considering your comments, XP really does seem to lend itself more to the mediocre/average coder. Certainly not the clueless bad-apple on your project who is only efficient at converting oxygen into carbon dioxide and also certainly not for the more experienced engineers who know how to get the job done and know when they need to communicate with other engineers to expedite the process.
I, too, have wondered about that idyllic world mentioned in XP where the customer is always available to provide information. Hell, most of the projects that I've been involved in, whether product or service, commercial or government, people are ALWAYS trying to isolate the coders from the customers.
My current project is the very first that I've experienced, out of maybe 9 or 10, where I've been afforded a direct relationship with the customer and I love it. But, as you said, this is nigh impossible to find so I'm trying to enjoy every moment.
Yeah, yeah, yeah. I'm "lazy" in that I code simple so that I don't have to remember a lot. I also get my work done long before my slacker colleagues. I think I'm doing my job right, thanks. Besides, I definitely have impatience and hubris down pat.
Half the the replies are along the lines: "Geez, some dumbass will be my partner and drag me down like an anchor. Without them I can write my godlike code in peace..."
I doubt there are many people in the world that can really make this sort of claim and be justified. Certainly not half the peanut gallery known as slashdot. We all just like to think we are that good, because we can always see people who seem alot worse.
Paired programming will create higher quality designs/code and think thats what software developers should be focusing on.
I will get back under the bridge now.
Less time spent reading /. per day means more time doing other stuff, like talking about movies and baseball. This is an OBVIOUS performance boost.
That's "Mr. Soulless Automaton" to you, Bub.
Amazing that they can use such a term for something as mundane as programming with a partner.
XP is more than that. It leads to more effecient projects. It focuses on coding the most important sections first and go back for other sections later.
Well, if you improve the code significantly from the process, then the testing, support, and maintenance can complete more quickly, and it can save a lot of money in the long run. Proper design (especially of interfaces) is one of the most critical parts of sucess.
--
"It's tough to be bilingual when you get hit in the head."
I'm sorry, but my experience differs. Perhaps your "star programmer" generated garbage in large volumes. There are people who generate great code quickly. Indeed, they are rare.
No method fits every situation and coder. Pair programming (to differentiate this practice from the other facets of XP) might be useful when coders are either inexperienced or merely unexceptional. Pair programming will slow down the star programmer and frustrate his need to get into that solitary zone where the code flies out of his fingers faster than a greased pig on teflon.
Holy cow.. my girlfriend's mom works in QA and she was telling me about this about ten months ago. For the longest time, I was half blowing her off, thinking the same thing-- guys at the beach playing volleyball or surfing and then sitting down with the laptop to hack..
-- jimmycarter
- coding standards - so people tend to write the same kind of code
- extensive unit testing - so that anything that breaks is detected immediately (before it goes in the repository)
and potentially some of the other practices as well (I don't have the book in my office right now, so I forget). Kent specifically says that it is difficult/foolish to adopt some practices without the others.I agree lots of XP seems like common sense. But how often do these practices actually occur? More often in successful projects?
Also, to reply to specifically to your objection to pair programming, several studies have shown that pair programming has a slight (10%) development time overhead that is more than made up in decreased QA and support time. For example, a 100 person-hour project which is completely separable will usually be completed in 110 person-hours by pair-programmers. However, the code is found to have something like 50% fewer defects, which translates to something like 200 saved hours in QA and support. Yes, it takes a little longer, but better code comes out.
hehe.. I reply to you with headphones on.. techno works wonders for me... :)
JOhn
Campaign for Liberty
"OSS has traditionally provided a better quality of software in which bugs are fixed more quickly"
Please provide me with some references so I can do more research.
Other than that, good arguments, although I am still not convinced that open source is truly better.
What is this sudden interest in Extreme Programming??
Yeah but if you read the XP material available (the books, for example) you'll find that the customer really has quite a special role in the XP software process, especially in helping the developers to understand the problem domain and to prioritize stories.
Taken from the XP point of view, developers really can't be the customers. The customer is the one with the knowledge of the problem domain the software is trying to solve. The online customer is there to answer the developers' questions and aid in their understanding of the software they're trying to build. In a developer-is-a-customer scenario this is impossible. You don't have the answers so you implement what you *think* is correct. Only to find out you were wrong. This has a great impact on the productivity and the quality aspect of the process. And better quality and increased productivity is what XP promises to deliver.
I think especially at the productivity part most Open Source projects have alot to gain. So at least from that point of view the OS projects aren't "naturally" implementing the XP software process all that well.
eXtream programming is eXtream because it provides the eXtream eXPerience...
Spoon not. Fork, or fork not. There is no spoon.
I think this is a matter of perspective, mostly related to how much confidence you have in your own coding ability. Extreme Programming is a great idea, and for most people, it will help reduce the number of bugs greatly. Most programmers, in my experience, don't have the ability to walk through every line of their code, envisioning every single variable down to the platform level, as they go. For them (again, this is most people), XP is great because it lets you sit there with someone who's job it is to do this so that you can program without having to worry about this. For those of us who have trained themselves to do these "dry runs" in their heads as they go, it actually slows us down to have to not only code but then have to explain every single line in words to the other person so they can understand it at the same rate that you type it.
If you're interested in extreme programming, you might want to read "Planning Extreme Programming", reviewed in this SlashDot article, oh, about 4 hours ago.
Actually, the topics are different, but I find it funny that they posted two articles using "extreme programming" to mean different things within a few hours of each other.
-Puk
of course that guy: infinite9, has not much clue about software engineering.
:-)
he even makes silly comments here or he is just sarcastic.
But some found it obvioulsy good enough to moderate it up. Those moderators also have no clue.
Thats normal, we live in a clueless world, I guess.
But why did one moderate him 'flamebait'?
Thats silly, he only says his opion, I do not agree with it, but a flame bait is something differen, would be nice if moderators would NOT moderate if they are not fluent in the topic the posting is about.
Regards,
angel'o'sphere
P.S. you should try it, from your heart. Then write again. You seem to have nerver done serious computer science, but that is common. Only about 5% of software engineers did or work in environments where they can. Most software engineers work under pre industrial working conditions. But all think they invented programming
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The idea that everyone should know the needs of a job but be good at maybe 2 or 3 details is brilliant.
Most companies have to have interpreters for interpreters for departments.
Get the coders to do some of the grunt work. You'll actually have less coding to do!
The message on the other side of this sig is false.
Even better, put it on IN PLACE OF the Lone Gunmen. What a shitty show that is...
What's MS's new OS have anything to do with this? Is this part of .NOT? err.NET ;-)
----------------------------------
Looking for hardware (Currently need: Large Etch-a-Sketch) Have one? See my journal!
Does anyone know of any schools that are currently or planning to teach Extreme Programming? Reid Hochstedler
I don't believe in any single development methodology. It depends on the group and sometimes even the project.
I am the director of development where I work. We are currently working on the release of a product, but shortly after the release, I plan on overhauling the development methodology. What we do works well, but it could be better. I think that's really the secret. Keep going back and examining what worked for you, and what didn't, and fix the stuff that didn't work.
I see some serious flaws in our existing methodology. I have nobody to blame but myself. I was mostly responsible for creating it and I endorsed it in the end.
After this round, the developers and I will take a couple days to go over what worked and what didn't work and look for alternatives. Among them, aspects of Extreme Programming. I'm a big believer in the pairing up aspect. There are a few really good things that come with this:
1: Developer is less likely to goof off
2: Second set of eyes can check for errors while one is coming up with the actual code
3: Different people have different strengths. In this situation, you get the combined strengths of both developers.
We will examine other areas of Extreme Programming as well, but this is definately one of my favorite aspects.
>"...if I had another person constantly looking over my shoulder, it would drive me insane.
This used to be referred to as a micro-managing boss!
When I die, please cast my ashes upon Bill Gates -- for once, make him clean up after me!
Yes of course, it is different, but if you read "The cathedral and the bazaar" and then "eXtreme Programming explained", then you see many point that fit, and many that don't at all. I've been to XP Conference 2000, the first conference on this topic, and it was then that I had the idea to do some research on XP in Open Source. Pity I didn't do it by now...
So, for one thing, pair programming does not work in OS teams. Even if we'd use an IDE that supports multiple users at one time with different cursor colours and video conferencing, it wouldn't be the same. But we could get nearer, a lot.
But then there is collective ownership or continuous integration and short release cycles, which is all kind of built into OS projects. Of course, there are OS projects without collective ownership of code, where only RMS may touch the code, but in most projects you only need to give some good contribution to get CVS write access.
What is very interesting, to me at least, is the on-site customer. XP claims that there should be a customer, the one who pays for the software, constantly in touch with the programmers, so they can ask questions quick and he/she can interfer. But who is the customer of an OS project? Noone pays, noone can claim "that certain feature like this and nothing else!". Sould OS projects take "customers" on their teams? Who would be such a customer? What may he/she claim, what not?
At least, I think there's a lot more to say about OS projects being XP than just "They are the same" or "They are completely different!". Anyone interested in further discussion?
This sig is stolen from someone who had a much better idea than I had.
Despite it's attractive name, Extreme Programming has little to do with all-night coding sessions powered by passion and caffeine.
Many of the notions put for the in the rules and practices of Extreme Programming make sense, such as "Make frequent small releases," but others are less intuitive, such as: "Leave optimization till last" (i.e., write the program, and then try to make it fast) and "Move people around" (i.e., just when someone is getting the hang of one piece of code, send them to do something else).
And some parts of Extreme Programming are just plum unrealistic. There should, according to XP, be two programmers at a single computer ("pair computing"), no overtime (let's see that right before release day), and "collective code ownership" (anyone can screw with any part of the code at any time).
It's a neat idea, a great mental exercise, but I doubt that it will make it past the trendy self-help phase into an accepted way to run a programming department. Some companies have experimented with it, but it will be a long time before the traditional caffeine / overtime / don't-touch-my-code programming paradigm goes away.
Got Rhinos?
Yeah. *quotefingers* "Groovy."
Got Rhinos?
At my job, I've either coded with another person looking over my shoulder or been the one looking over someone else's shoulder. Sometimes, it does make for better code or for less compile errors. However, I've rarely found it to be more than twice as good--which is what it would have to be to replace two independent programmers.
Apparently, of the rich, by the rich, for the rich.
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.
test plan? what test plan? Just write a little test that will exercise the method you are about to code. Then write the code that will make the test stop breaking.
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!
Um, Your name isn't on it. EVERYONE'S IS! Also, if his code broke your unit tests/acceptance tests when he tried to integrate his change on the integration machine it is his job to fix the damn code.
Moving people around
Yup, they have to restrict the movement to when a story is complete or to when someone is deep into the weeds and just can't get out.
--Angus
Actually, pair programming is kind of fun. You get to ride the bow wave of your partner's energy as you cut through the code. It does assume that your partner has some skill, but it doesn't have to be equal. It just has to be close. One of the things that is being accomplished in a pair with a less skilled member is bringing that partner's skill up while he helps you to remember the little nitty crap you might forget.
--Angus
Peer review in a metting setting sucks. It is hard to critisize someone's boneheaded code without offending them and putting them on the defensive in a big meeting room. With pair programming you can say "But how about WE do it this way instead?"
Chris, this is NOT an attack on you. I see that you are just offering a way out of pairing for those that can't hack the social interaction.
--Angus
Yup, esp helps in making sure that the unit tests get written befor you start coding :)
--Angus
ObXProgramming: All the extreme programming techniques in the world are irrelevant if the requirements for the project are not well-designed and set in stone.
Um, one of the main points behind XP is that the requirement will change and so it allows them to change. Customers can add/change/remove Stories on a whim. They can even reprioritize the stories. I agree that you have to have stories to develop. But if a customer wants to change the code they just write a new story, give it a priority, and give the card to the programmers.
--Angus
sounds like salvia to me
I ate my sig.
This is similar to the way that I beat Diablo 2 on the more difficult level. You see, I had the mouse, and was in charge of whacking him, and my friend manned the health potions and quaffed one for me everytime i got close...
Years ago, my brothers and I did some sort of extreme programming for a major project - I sat at the keyboard, doing the typing and thinking, while Hannes sat next to me, commenting, correcting and thinking further ahead.
Meanwhile my youngest brother, Flo, solved the thorny mathematical problems (get yourself a tame mathematician who doesn't like computers - they're great!).
The code grew very fast indeed, and contained surprisingly few errors.
However, I do get along with my brothers very well - don't know if I could do that with a semi-stranger.
Ciao,
Klaus
---
"What, I need a *reason* for everything?" -- Calvin
Free PC version of ChipWits at http://www.breueronline.de/klaus/chipwits/
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.
As much a 133t c0d3rz talk about "flow" or "being in the zone", it is not that common, and the whole point of pair-coding is that supposedly people have been suprised in the past when under forced circumstances, pairing coders actually produced better results than keeping the coders seperate. For one, they spend less time on Slashdot, I'm sure.
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
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
Is blatantly false. It's actually nearly impossible to make the claim that one is better than the other. It depends on your criteria. From a technical standpoint OSS has traditionally provided a better quality of software in which bugs are fixed more quickly. Not to mention the fact that you are free to modify it any way you'd like. So from my criteria, freedom, power, and quality I'd say the reverse. Now if your criteria is rigidness, less rights, and a lot less power. Then yeah, closed source is better. As for the issue of making money, hell that's not even a factor in my book, but just to make a point there are plenty of companies that do make money at OSS.
One other vitally important point. All software is open source in the situation you've described. No not in the sense that the source is available to anyone who wants it... but the developers, which could be anyone in the case of OSS, or the employees in the case of a proprietary company have access to the source code. So it's not reallly closed is it? Not insomuch as it pertains to development.
So basically you're pretty much wrong on all counts. Collaboration has EVERYTHING to do with open source... it's not possible without open source. (Except of course in the extreme, no pun intended, case that each programmer writes a subroutine and "owns" that bit of code, which is assembled into the whole by someone else.
I'm the big fish in the big pond bitch.
Let's go back to the concept of trivialness. How do you know that these proprietary products aren't also trivial (definitely you ridiculous adjective)... have you seen the code for any of these products? If OSS products are so trivial why do they dominate the server world. Why do the people who now the technology best flock to them?
I never said that OSS is universally better than proprietary, although it is morally if not for quality reasons. I said it was traditionally better. There are just as many poor, (actually more) poorly written proprietary apps than there are poorly written OSS apps. Just scan a download gateway and look at all of the crap that people have written
OSS "zealots" can more accurately assess the quality of software. For one they know how the software works, and they can modify it to suit their needs. It's the closed source zealots who have a problem judging quality, they're trapped in their box of constant upgrades to keep up with bloated software that constantly crashes. They can change their software, they have to believe that their software is better, because they have no other choice. It's sad, the question "where do you want to go today?" is most often answered by, to go get a cup of coffee while I reboot my machine for the second time today.
I'm the big fish in the big pond bitch.
One of the foundations of the Extreme Programming methodology basically reads as such: "Users and Developers are on equal footing". This is basis for many of the practical guidelines of XP. As a developer, I'd like nothing more than to see this happen. As an employee of a large corporation, I'm cursed with knowing this will never happen and thus most aspects of XP will fail. Users (read: managers) don't or can't understand software and consider business concerns at the same time. And when it comes down to it, you know which will suffer first. While I think many of the ideas in XP are good and would like to see the methodology as a whole implemented (even if it's just an expirement), I could readily see some of the management friendly aspects (short release dates) being used to the exclusion of some of the more programmer friendly ones (code review, refactoring). Does anyone else envision this happening?
Of course, distributed hackers have been doing this for years on open source projects.
/. reader knows and would share it with us.
Please let us not compare XP's success to Open Source success. Anyone who has been in Open Source for a while will tell you that one of the top reasons why Open Source is successful is for the fact that virtually ALL Open Source projects are re-engineering projects based on existing projects.
Linux was not a new *idea* -- it was based on a pre-implemented *idea* -- the same is true for virtually all successful Open Source projects (yes, MS's "innovation" falls into this category too -- in case if you have not yet figured out why they are successful.)
There is a link on the net point this out in full details. I don't know where it is. Maybe a
I am not trying to be a troll, but it is important to set the facts straight.
---------------
Sig
abbr.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Granted that extreme programming is quite a buzz term that can be used overzealously, I've actually found that pair programming is very effective. Last semester I had a programming languages course in which we wrote several versions of an interpreter, and we were required to use pair programming. My partner and I caught almost all the little bugs that usually pop up as we went, and we found it much easier to get past places where we were stuck, since we were both thinking about the same thing and could discuss it without one of us having to catch up. Without saying anything about the other hyped aspects of extreme programming, I think this is definitely one simple technique which can help turn out better quality software projects.
Mea culpa. All I've been hearing about, at least on Slashdot, is team programming. "A little learning" and all that...
I'll be hearing a presentation on XP from Martin Fowler on Thursday night, presented by the Chicago Software Process Improvement Network. After that, I'll be fully qualified to make sweeping generalizations.
--
Specifically, nothing is needed beyond the ASIN/xxxx/ in the URL. In the post above,1 6/ 1 6/o/qid=986325104/sr=8-1/202-6221066-4150208,
http://www.amazon.co.uk/exec/obidos/ASIN/02016164
is just as good as
http://www.amazon.co.uk/exec/obidos/ASIN/02016164
and doesn't include your session information.
I'm not sure anyone could actually do anything with that session info, but why bother finding out?
ObXProgramming: All the extreme programming techniques in the world are irrelevant if the requirements for the project are not well-designed and set in stone.
--
Yeah, but the two of you probably fight it out like cats and dogs over the spacebar...
Pair programming isn't a solution, it's a tool. In fact, it's a fantastic learning tool. When I started programming (13 years ago? good lord, I'm getting old), I sometimes programmed with a friend in exactly the manner described in XP. I learned a hell of a lot and I'm a much better coder for it.
In that respect it's a lot reading other people's source code. You learn a lot, but it doesn't necessarily make your current project better.
One caveat is that both programmers in the pair need to be at similar levels. A novice will hold back an expert, unless the expert is training the novice.
Also, once you do it for a while (years), you tend not to need it anymore. If you're an expert, you'll just end up using the other person as a crutch.
As for figuring out design flaws, that can be done before ever sitting down to code. A good design phase before implementation will find most of those flaws. Design is inherently collaborative, and serves that function of pair programming. Pair programing may be able to take care of it as well, but it is generally recognized that XP falters with larger groups. Hence, the design phase is the norm for large projects.
I'm amazed every time I read someone posting on Slashdot about what an awesome coder they are. To me, this invariably means the poster is insecure and needs to brag on Slashdot to shore up his ego. The best programmers I've met never brag about themselves. Their work speaks for itself. It is clean and elegant. It's not full of 800 line functions with no comments. It's modularized in a way which makes sense, and is documented thoroughly - to the tune of one line of comments per 2 or 3 lines of code. And it's formatted in an aesthetically pleasing manner which makes it easier to read and understand. The braggarts, on the other hand, usually come on strong in the beginning so they can make a big impression on you (and at first this works pretty well), then gradually you learn that they're full of shit.
Extreme Programming might help reduce the jackass ratio, and I think that's a good thing. The exact methodology isn't so important; what matters is that programmers are being taught to work together and create software someone else can develop and maintain. Yes, there are lone wolf badasses out there who can put us all to shame. But you're probably not one of them - and if you're one of those people who brags on Slashdot about how great you are, then you're definitely not one of them.
XTREME HARD-DISK DEFRAGGING!
"DUude, he's catching some SICK sectors!!"
Ok my karma is maxed out. When do I become Enlightened?
Geez. We've been doing it all wrong.
I had the monitor, he had the keyboard!
It took us three hours to code "Hello World!".
If you watch TV news, you know less about the world than if you just drank gin straight from the bottle.
I personally would prefer the concept of "Extreme" Programming to be like Extreme Gaming. Take a bunch of hacks, give them an assignment, like break the CCA in fewer than 300 characters, and first one who wins gets $10,000 and a legal injunction. Make coding a spectator sport... I'd watch it... might even participate. that would be really cool. even have trading cards... heh
I've been the tech lead helping put together a quasi-XP environment for the past six months.
First of all, XP is a bag of techniques, not all of which have to be used for the whole thing to work. It is not a monolithic system.
Second of all, the key IMHO to XP is the fact that the customer plays a central role. Every few weeks you demo your working code the customer. You tell them about what more needs to be done, expressed as features that make sense to them (stories).
So here's the problem: what happens when you don't have a direct customer? I can think of only a few examples of software development when the people writing the check are available, educated, and interested in what you are doing to provide you the assistance you need to stay on target. Onsite development of custom code in a corporate IT department is one (a la Chrysler's C3) and that's where XP was invented.
Does open-source software have a customer? Hmmmmm....uhhhh....NO. You cannot be the developer AND the customer at the same time. I'm not sure a loose "sponsorship" by an inner-circle developer on a large project counts really, either.
Premature optimization is the root of all evil
, and I'll say it again.
XP is great on paper, but you'll have a better chance at finding a snowball in Hell then finding managers who are willing to spend this kind of time to manage this properly.
Where talking about people who can't even write a proper spec let alone be willing to sit down with coders and go over ever little detail of what the coder needs to write.
Most assignments go like this:
we need something to do X, please do it.
then you do X.
it doesn't do Y? that not what we need.what have you been doing?
The Kruger Dunning explains most post on
Back in the days when I and a few friends of mine were addicted to Ultima Online, and I was the only one with internet access (28k modem), we used to play that way. One guy took the mouse, another one did the typing and all the others were debating about what to do and looking up stats on printouts, or doing translations to and from english for the guy at the keyboard (I'm from Switzerland). Our english really improved because of UO, althogh a lot of the words we learned aren't relly useful outside of fantasy RPGs :)
Is get a good book for it, fortunately, there is just the thing you're looking for about four articles down.
This is right after Extreme slug racing.
DanH
Cav Pilot's Reference Page
Cav Pilot's Reference Page
UNIX - Not just for Vestal Virgins anymore
...if I had another person constantly looking over my shoulder, it would drive me insane. The methodology sounds good, but as long as the other person is out of projectile range.
--
--
#nohup cat
Since when is this news? I'm assuming that the "new" in "news" means that this would be a new idea. Umm... I've known about extreme programming for at least a year. Is the next post going to be "Nanotechnology. The theory of using nanomachines to do work!"
Can we stay current, please?
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
It's probably too late for this observation but the concept of programming in pairs has been suggested before. In fact, there's a very old (by tech standards) book called The Mythical Man Month by Frederick P. Brooks, Jr. The copy I have is the 20th anniversary edition, published in 1995, so these ideas are at least 25 years old.
Brooks is, as the Author's Bio states, best known as the "father of the IBM System/360". He was a project manager for its development, and later was manager of the Operating System/360 during the design phase.
It's long past time to prove that we can learn from history, and stop claiming that we just now originally thought up ideas that have been floating around for decades, or longer. If you'd like to find this book, its ISBN is 0-201-83595-9.
PGPKfp: ADD9 DF80 D6E7 1DB5 051C 1026 3489 4B37 2109 F19B
Anybody who's done team-based programming competitions (at least those that were moderately successful, and even most of the ones that weren't) should know this from experience.
As someone who's done both team based and solo competitions, working in pairs GREATLY reduces debugging time, both in the other person catching errors when you make them, and having two sets of eyes looking for the bad code after the fact.
Dark Nexus
Dark Nexus
"Sanity is calming, but madness is more interesting."
- Planning - up front, and iterative
- Short release cycles - small incremental builds build confidence in the build system, test rig and final kit
- Simplify design - bite off the minimum amount of work for each release
- Use methaphors - use a common familiar naming system for features and components whenever possible
- Refactoring - refine code when necessary. A subject upon itself (check out Martin Fowlers book)
- Unit testing - unit test, unit test, unit test. If you want to write the code, you write the tests first. Run the tests as often possible (whenever you change the code) With a good unit test suite, accidently introducing bugs as a result of refactoring code isn't as likely
- Continuous integration - merge changes as quickly as possible, keeping everone in sync. A decent configuration management tool is essential.
- On site customer - customer has direct input to requirements/priorities.
- Code ownership - or rather collective ownership of code. If you see something that should be changed, you don't need to request permission. Do it.
- Coding standards - required for Collective ownership to be possible. Rules are required to ease readability
- Pair programming - As described already
- 40 hour week - if you're burnt out you'll make mistakes
The point is, XP uses *all* of the above practices - they're an interdependent matrix of practices in which each supports many others. (For example, continuous integration facilitates small releases which in turn facilitates iterative planning etc, etc.)If you choose not to implement several of these practices then the methology starts to break down. I think this is what makes it so difficult for a lot of engineering organizations to switch to XP - there is simply an awful lot to change, a lot more than buying desks which can seat two people...
oh, blocking slashdot.org in the company firewall would also eliminate a significant distraction that has been known to yank certain programmers out of the zone. ;>
wish
---
hehehe.. I'll start writing my book. :)
wish
---
This would make a great Mountain Dew commercial. Instead of extreme mountain biking, or skateboarding (with a spaceship). Extreme Coding! It's the only think Mountain Dew is good for anyway...
I can see it now:
Keannu: Better refactor that code man, There's at least two lines you could take out of that "if" statement! [slams dew]
Dude: Right on!
XP is related to Open Source methodology, in that they both make use of evolutionary methods rather than design methods.
See my article on evolutionary programming here.
With both XP and OS development there are processes which act as 'mutation' and 'selection' factors that act on source code. Programmers provide 'mutation' - or new code, while the users select which versions end up actually being used.
I should point out that I am not saying that 'micro' planning does not occur by developers - just that there isn't a single Big Plan(tm) from the start like there is with a more traditional approach.
I prefer the magic eightball to a code partner.
Q: Should I rewrite this subroutine??
A: Please ask again later.
Q: Should I rewrite this subroutine?
A: Predition hazy.
Q: Should I rewrite this subroutine?
A: Maybe.
Q: Should I change the scope on this class field so that I can access it directly instead of using those silly getter methods?
A: Yes!
Q: Should I make my code backward compatible?
A: No!
The great thing about the internet is that there are computer simulated magic eightballs available to help you with major project decisions. This is indeed one of the major contributions that cutting edge technologies such as Javascript and ActiveX have made possible. Not many internet visionaries make mention of this fact, however I felt it was important to extol the many virtues of this incredibly useful project management tool.
- Pat
-- Good judgement comes with experience. -- Experience comes with bad judgement.
Almost everyone I've talked to uses various bits and pieces of the extreme methodology (unit testing, peer review, whatever); myself included. I haven't run across anyone that actually implemented the whole paradigm, from arrangement of office space down to pair coding. Has anyone done this? How did it work? What's the fallout of two people spent writing the same code to fewer people spent bug fixing? Cost savings? Productivity loss/gain?
there are no stupid questions, but there are a lot of inquisitive idiots
Well it worked for everything except the XFL
In this case it is used to hype this method of programming... Is it truly extreme? My understanding is it is only for small to medium sized projects, that isn't very extreme...
"If you can't beat them, arrange to have them beaten."
-- George Carlin
"It takes many nails to build a crib, but one screw to fill it."
I would only consent to work in a programming duo if they promise to pair me with somebody who also needs regular (every 15 minutes) breaks to read /.
Woody!
Please mod me up. My grandma might not make it to the weekend and she always wanted me to hit karma cap.
while working on project where we were working with new technology a few years back. we were a group of pretty experienced people, but none of us had ever really worked with this new tool, and it was very handy to take turns digging through the spec(almost non-existent and updated daily) , while the other hacked away at trying to implement our interpretations of the said spec. basically like firing of one process to look for answers, while the other tried to implement them in parallel.
it was far more effective as far as the 'zone' argument goes, and also good for finding mistakes faster... but i've never found it so useful for things you already know your way around.
Programmers must write tests for their own programs before they begin coding. These tests are used instead of an independent "quality assurance," or testing, group--a technique that will save time, according to
Extreme's advocates.
We know that programmers can fake things damn well. I know that "demo" versions usually work very well, I would have serious problems, as a Professional Test Engineer, with allowing programmers to write their own test scenarios. I have the bad feeling that these scenarios would test beautifully but a little outside of this box and they'll break. As a programmer and as a tester, I have some issues with this type of QA. The rest of it I agree with, but letting the programmers define their own test scenarios is a recipe for disaster once you get this into the mainstream and get the programmers with lower work ethics producing an appreciable amount of software. The group of programmers who just "make it work" and who fake it, and we all know they exist, hell some of us may be them, will produce absolute crap when allowed to write their own test scenarios, but that scenario will work beau-tee-fully. I don't trust the programming community as a whole with this type of Quality Assurance methodology.
Steven
-- I have marked myself unwilling to moderate-- I don't have other accounts to artificially inflate the karma of
. . .
Most of the principles mentioned in this article sound more like common sense than anything else; delivering something simple quickly and building on it, constant feedback from the user, optimizing code for simplicity... Some of it may fly in the face of pointy-haired-boss practices (most corporate types want something FINAL before it's sent out, so they can safely ignore the customer from then on), but really, it sounds like common sense. So why treat it like a 'movement'?
_ The bureaucracy is expanding to meet
the needs of an expanding bureaucracy.
This kind of reckless ignorance of Slashdot's own archives is bordering on obscene.
The idea of peer review and testing during development is not new. So you have buddie,wowwee. Maybe what is new is the idea that software development is not some weird voodoo that mere mortals can't understand. Ask an engineer if any of these idea's sound new.
By definition, a government has no conscience. Sometimes it has a policy, but nothing more. - Albert Camus
I tried extreme programming, and loved it. Yet it is quite different from what is done in Open
Source computer community, often an opposite.
The idea of "four" eyes looking constantly and together at the code that is written, and constant
testing using automated tests, are the heart of EP. It cannot be substituted by "distributed"
programming, or mass testing by the whole community.
Students have been doing it for ages. In every college or university there are a lot of people that work in groups. There are some obvious advantages. Pair up people who are good at different things but can still manage their ass around with the weaker trait.
This way not only will the stuff will get done faster, it'll also help CS students (or others) to communicate with each other and we all know that all of us nerds can use a crash course in comms.
However, in critical environments the pairing has to be done sensibly. Stick two dumbos together and you're sinking with them.
I guess all I'm saying is that, this is a neato idea if used properly. I am all up for it.
Write your tests first!
Write really good, exhaustive tests. Then go write some code. Code pass all the tests? Then you're done for now. Code failed some tests? Go fix the code. Of course you can expand the test suite as you code and realize maybe there's special case you had failed to consider, or whatever.
This technique alone has made a vast difference in my productivity as a programmer. Once in a while I slip and get lazy and don't write tests first, and I invariably regret it later, because I do something dumb that would've been caught if I'd only had the tests instead of thinking to myself "this is so small and simple, I don't need to test it now".
Of course, having great tests is especially helpful as you change requirements and refactor and optimize, because you just run your test suite and if it's clean you can be confident your changes didn't bust anything.
"Biped! Good cranial development. Evidently considerable human ancestry."
WHAAAT!! An informed SplashSlut reader? Someone who thinks that XP is more than pair programming? ...then there's my favorite values: YAGNI and DTSTTCPW.
meh.
Well, I hate to break it to you, but I sure wouldn't hire someone with this attitude. You're not writing code for a company to have it squirreled away with no one there to look it over. They own it, not you, and they can do what they want with it. Furthermore, if you're not confident enough to have other people challenge you on your code, then you're probably too insecure and/or inexperienced to be terribly great at your job.
I say, bring it on! I want people to look at my code and show me my mistakes. That's how you learn.
www.Jackassery.com
For a one-off, this is probably a pretty sensible strategy. The problem is that most programs of any utility need to change over time as requirements change. The XP strategy would seem to involve throwing more programmers at the program every time a change is needed. In contrast, if someone developed an insight into the problem space, they might be able to build a flexible, configurable program. A configurable program can change with the changing requirements, without the need for an extensive reprogramming effort with each change.
The insight approach, which requires a certain amount of peering into the future and building functionality that you might need, is denounced as "gold-bricking" by XPers. But I wonder what the total costs are, once you factor in all the maintenance effort -- in code that just manages to do what it needs to, as well.
(You could argue that 9 out of 10 large software projects fail. So if XP delivers 3 times out of 10, it's cheaper to just build an entire new system from scratch every time you need a change. I'm not convinced.)
You wouldn't hire someone who has just said he would experience stress and burn out quickly from being forced to implement the latest buzzword? You must be in HR to be this sharp.
One of the most potent benefits of pair
programming is motivation. As one poster said
in another part of this thread, "I wouldn't like
it because we wouldn't be able to agree on which
slashdot article to read when goofing off." But
that's the point: pair programming keeps you from
goofing off.
Having used this technique in an open lab setting
before, I know it works. At our organization, we
reserve pair programming for crunch periods. It
does tend to be quite taxing.
It is, however, generally quite effective.
C//
It's all great until you get paired with the dumb guy... *shuder*
you're actually right, my apologies. i was speaking more towards the term "extreme computing". when i think of that phrase, i think of the tmrc, i think of caltech. i could have been more precise.
My .02,
My .02,
zencode
iactivist.org/jason
My .02,
My .02,
zencode
iactivist.org/jason
watching flies fuck
watching paint dry
watching someone code until they sweat
what a dumbass phrase. worse, it was stupid when it was used for things it could reasonably be appended to like monster trucking or ...fuck, i dunno. mud wrestling? hmm. slashdot: all the social skills of a nerd combined with all the brainpower of a hick sport. yay!
My .02,
My .02,
zencode
iactivist.org/jason
...while the other programmer sits beside him, hands off the keyboard, and just sits, watches, and comments.
And all this time I thought I was just being nosy. Go figure.
I got my Linux laptop at System76.
I'd have to agree with you and if I had mod points you'd get some. You'd think it would be impossible to get into that tunnel vision space where it's just you and the code and your caffinated softdrink of choice. I know it's possible in pairs it's like when $sports_team works so well together you'd swear they all knew what each other was thinking, ok abstract idea but same principle. Generally the coordination level would be higher between the two coders thus less time is spent on integration.
I think as one of those interesting side effects XP might help often solitary coders develop that little bit of extra diplomacy they might be averted to. Turning constructive critism type code reviews into less of a thing people would rather avoid. I'm positive this approach won't be easy for everyone to adapt to but I think it's one of those things that would quickly grow on you.
"Zone Coding" I smell buzzword!
Your comment is moderated as funny. But, actually, I did exactly that several number of times, while doing my programming homework and other stuff. Once your experienced, you are in fact faster than if your programming alone. A friend who jumps immediately to the same place is even better than an emacs shortcut.
I'd thoroughly recommend both the book and the methodology it teaches.
Actually, something like "coding under Xtreme conditions" is actually part of the training that soldiers in IDF computer units receive as part of their course...
I'm sorry, but I've been reading about XP for at least a year now. Why is everybody just hearing about this?
man, i am against this extreme programming cos i want to pick my nose in peace in my cubicle while i am thinking deeply on the problem. nuff said.
The customer is part of the problem. You cant expect him to provide the solution
As the designer of the software, its your responsibility to understand the problem and provide the solution.
When I design software, I take this approach:
Maybe most of you know all this, I just tried to summarise what I did to develop my product. Thanks
The great thing about team programming is that the employer can make sure that one isn't on /. while the other is programming.
-----
You stupid bastard, you don't have no arms left. It's just a flesh wound.
And in other news, two extreme programmers, who were recently working on a project for the Pentagon bombed the World Trade Center after complaining that the local workers their were using proprietary software.
-----
You stupid bastard, you don't have no arms left. It's just a flesh wound.
To answer your question "who is the customer of an OS project?", the developers themselves are the customers, at least traditionally.
Open source came about because developers had needs for which existing software was too expensive, or non-existant. Therefore, they wrote it, for themselves. They then shared it with others.
--
--
Unscrample my email, win a prize.
Don't know if this is addressed in the literature, but wouldn't you have to ensure that in each pair both developers have equal skillsets and productivity rates? Personally, having to explain everything that I do as I go along would drive me nuts, as a lot of it comes from the fugue that you sometimes enter when coding, when you're "in the zone", so to speak. It's often easier to just do something than to explain it to someone else. alf the fun for me is that developing *is* a solitary activity... I enjoy that.
CdrTaco must have typed this "extremely" (quickly and without planning). His grammatical error is glaring. "with less errors" should be "with fewer errors" since errors are countable, ergo we use 'fewer' rather than 'less.'
My partner is my twin brother. We often code as a pair when the project is particularly difficult. The second person just watches and points out errors etc. You would be suprised at how many errors the second person catches as they are being made. We don't do it every day but there have been some horrendous projects that would have been impossible to complete without two brains. Also note that a good quality/good sized monitor is very important for this.
I've been working as a code monkey for a couple years, and two months ago I convinced my boss to hire one of my coder friends (Drunk Gary). We've been working on the same project together, and we've found ourselves often working on the same code simultaneously (cooperative not seperate). I've found that I am more productive and the code that D-Gary and I come up with is much more finalized that what I come up with by myself.
Rock over teamwork, rock over chicago.
-Reb
XP is a NAIVE (some silly) idea. it reminds me the 10 steps to lose weight or 10 ideas on how to get rich .... If I work with a guy at my shoulder, it don't guarantee that the resulting code will be better. If some guys are doing intensive test it does not mean that they are finding bugs. If I rebuild a project by every 24 hours I am diverting effort on a secondary activity. First you must care for the design and it is better to do it with few experimented persons. The result desing will impose the correct tools to build the solution, so it implies that only some programmers of the staff would be able to be assigned. Before coding you must prove that the model and algorithms for the solution are correct, and there are no harmfull side-effects. Again it is an activity for few selected persons. The most silly concept is designing while building (who is a very common practice, also as cut-and-paste), the result is POOR, BUGGY CODE and finally WASTED TIME. XP concepts are more like a recipe to be applied in an activity wich indeed needs much more than a simple recipe.
Arturo Borquez
>> 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.
I know, replying to my own post is bad ettiquette. It just occurred to me that I didn't completely get my point across with that comment.
Since construction does not account for the majority of time during project development, you might think I was saying that the effects of XP would be even less!
However what I forgot to say was that the impact of quality and design on project development is huge! If XP increases the quality and does the right things to the design early enough, that effect alone could have huge beneficial repercussions for the project schedule.
"See, these programmers are the most productive, their dials go to 11."
"That's odd, how productive are they?"
"Well, most programmers' dials only go to 10, so 11's like 1 higher."
(apologies to the Spinal Tap folks)
--
"X-Treme Programming", huh?
Now I'm waiting for one of those Mt. Dew commercials to feature a pair of hackers in a dimly lit cube, their faces underlit by the screen, argueing over whether or not a mutex needs to be locked in the current thread execution.
Personally, I stopped "Do'ing the Dew" once I got a prescription for a caffiene drip.
While we work, we work in the workspace. We sit paired at one of the dev stations; it doesn't matter which, since we keep their configurations fairly standard. Between tasks - and our boss encourages frequent breaks between tasks, to keep people from burning out - we go back to our own offices, where we have our own computers (customized however we like).
That's when we get to read Slashdot, or do e-mail, or whatever. After we're done break, we go back to the workspace, pair up again (often with a different partner), and continue working.
Nor do we 'share one salary'. The pay is pretty good, especially since this method has made our team the most productive in the company (we're the only one using XP... we're also the only one who have met all our deadlines despite having harsher deadlines than the other teams).
Being the 'golden children' who meet all their release dates means there's bonus pay for the team to go around, too. ;)
--Rachel
For example:
- XP's testing philosophy is good. Instead of just writing code and hoping it works, you have to conceive what you want, and write a test for it. THEN you write your code... go back and change the test afterwards if you have to. All these tests are kept around in a test suite and are part of the process. Before you commit any changes, you have to make sure all the tests still work. This way, you learn quickly if you broke something else.
- Pair programming really does let errors be found faster. My experience has been that four eyes looking at code are better than two. It's like a smaller version of Linus Torvalds' philosophy that 'given enough eyes any bug is shallow'.
- Iteration/Story/Task Methology Works. Take a hypothetical messaging client (not a project I'm working on, but the XP team I'm on is under NDA). Chopping an overall revision cycle (iteration) up into larger features ('Make project work with newsservers') called stories, and then smaller tasks within a story ('Add NNTP protocol', 'Add NNTP security/login handler', 'Add NNTP cancel ability') really does work. If a task will take more than one pairing session, it should probably be broken up into smaller tasks. Then you can just walk over to your board, pull down one of the tasks, and get to work.
- Programmers Remain Sane. We make a point that between tasks, we take a break. We leave our common workspace (where all our pairing stations are) and go back to our own offices to read e-mail, browse the web, make phonecalls, whatever. Then we come back and switch partners around and keep going. This actually is more relaxing than just being locked away in a cubicle coding all day.
- Faster feedback. Every time we commit a change, a build is automatically kicked off. Our 'customers' (in my case right now, other departments internal to the company) can pull down any of the builds for a day and try them out. If something breaks, we hear about it (BOY do we hear about it!) within an hour or two, since their timeline/deadline depends on our code doing what they need! Moreover, if a build breaks, we all get e-mailed. And if the test suite fails, it treats the build as broken. Believe me, it encourages keeping the code working!
Now, there are flaws, too. Obviously, there are people who just won't be able to work in pairs. Our team was assembled from the beginning by hiring people with the input of the entire team. ("Could you see yourself pairing with this person? Do you feel they'll fit in on the team?") As a result, we have a fairly coherent and competent group. Trying to convert existing teams to XP could present problems, though.And it does take a little while to get used to pairing. We use pairing stations with two keyboards and two mice, and try to trade off who is 'driving' every so often. Keeps both people awake/aware and focused on the code.
XP isn't for everyone, no. It isn't for every project. But in my experience, having done stuff from database to video game to compiler work, this XP team is tackling some of the most difficult code I've worked with but also making far faster progress. We share our knowledge, we each learn various areas of the code and improve our expertise, and we almost never break a build.
If it works for you, use it! :)
--Rachel
--Rachel
So does Slashdot.
Bork bork bork!
I don't think XP is as good as many would like to say. Paying two people to do the job one person can do isn't as efficient from a payroll perspective, and from my experiences it does not improve the speed of development, if anything it only slows it down.
I think that closed source software can in fact be quality software, and open source software can in fact suck big time. There are many closed source software packages that work great, are stable, relatively bug free and easy to use. There are also numerous open source projects that are unstable, filled with bugs, and just not worth using. To say that open source inherently produces better software and closed source inherently produces poorer software is complete wrong. I think quality software can be developed in 2 way. 1. Brute force. Lots of developers. Lots of testers. Lots of implementations and choose the best one. 2. Smart project management and planning, a good software architecture and design and quality developers working as a close knit machine. Open Source is generally #1 with a bit of #2. For the most part though it is a group of hackers developing, re-developing, hacking, implementing, bug fixing, testing, more bug fixing, etc. Now, I am generalizing a bit because there I have seen some good project management going on in the open source community but often that is not the case and projects are hacked together with vague goals or project specs from the start. Closed source projects that I have been involved in are sometimes #1 with fewer developers so the results are often not that pleasing but genererally closed source strives to go with #2 because it is more efficient and cost effective. Unfortunately many closed source software development projects are poorly managed and/or managed by the wrong people (marketing people and non-technical people). With the right mix of management, project design, and good developers I honestly believe that quality closed source software can be developed. Extreme Programming is trying to formulate a method to create the right mix.
You make some good points but again, to claim that a closed source OS is inherently going to be lower quality software than an open source OS is wrong. Try using BeOS. It is very stable, easy to use, and fairly well engineered (i.e. the pieces all fit together nicely). The problem for BeOS is lack of quality apps because it's popularity hasn't hit critical mass. You say "general opinion is that software will continually break" and that is somewhat true. That also reflects sadly on the state of software engineering. Software should not be expected to break but it does and the reason for that is poor software engineering and poor management of software projects. This is where methodologies like extreme programming come in. Whether it works I can't say but it is interesting.
Extreme programming is like extreme skiing. It goes downhill very fast and usually crashes somewhere along the way. The only situations where I've seen succesfully applied is in training new recruits. Usually one of the fools ends up doing all of the work.
At my old job we did code reviews from time to time on things before we shiped them. They were very helpful. I learned a lot and I think we found a lot of bugs in our code that might have made it into production. Now for a code review to work you need everyone to check their ego at the door. Yes people will pick nits with your code. But if you know when you write it it helps you to write code carefully. And you know there is no programer in the world so great that they can not learn something from someone else. And none so great that they do not ever make mistakes.
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.
Erlang Developer and podcaster
I definitely admire XP, and have practiced a few permutations of it. Unlike many here, I think the whole thing is good and useful when practiced together. Yes, including PairProgramming and SimplestPossible :-).
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
That's why Linux is great. You can fixup that useless caps lock key to be the left-side enter key.
If tits were wings it'd be flying around.
Two bodies at a computer is more efficient because of {insert psycho-industrial babble here}.
/. right now. THAT'S why it's more efficient.
OK, we all know that if there was somebody else in the cubicle with us, we would be working instead of reading
If tits were wings it'd be flying around.
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
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
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
Based on some of the negative comments, I guess I take something entirely different from this Extreme Programming thing. I must preface this by saying I have not read every XP book ever, but they are lying around our office and so I've leafed through them...
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.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
... whoever was riding "shotgun" became extremely bored while the fellow "driving" became frustrated that the guy riding shotgun would come up with ideas in the middle of the driver's typing.
r ammingcostbene/pairprogrammingcostbene.htm for a study with evidence to the contrary. (Pairs took slightly more than half as long to "complete" a problem, but did so with so many fewer bugs as to more than make up for it.)
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."
Stupid job ads, weird spam, occasional insight at
P. J. Plauger [was] 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.
This happened back in the 1970s, and was written up in Constantine on Peopleware. (See also "Strengthening the Case for Pair-Programming" (Google text version).
Stupid job ads, weird spam, occasional insight at
I think that working in pairs would provide just enough distraction to never get into the zone.
... grow. If the less experienced person doesn't volunteer to stretch, the more experienced person is likely to suggest better ways to do something, which the less experienced person wouldn't normally have been exposed to.
... it adds up fast.
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).
Stupid job ads, weird spam, occasional insight at
I agree with your first point that distributed internet style coding is not like pair programming. Of course they could be combined pretty handily.
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.
Having tried XP and given up on it, my major point of contention was pair programming. Both my colleague and I are fairly experienced and relatively agressive in the pursuit of our work. As such, whoever was riding "shotgun" became extremely bored while the fellow "driving" became frustrated that the guy riding shotgun would come up with ideas in the middle of the driver's typing.
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.
I haven't heard of the tag "Extreme Programming!" before, but I've done some of this kind of stuff working on group projects in school and this is what my experiance has been.
:)
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
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.
--The basis of all love is respect
The article aside, XP itself doesn't say that it solves all the problems. It even notes that it isn't even a good idea in all cases. Don't write fly-by-wire code with it, for instance; it's not that bug free (for that you need stuff with MTBF in centuries). As far as bad programmers go, software development isn't flipping burgers. Bad programmers produce bad software, and nothing short of turning them into good programmers is going to change that. Even UML, practiced by bad programmers, produces bad, UML-compliant software. XP allows mediocre programmers to create half-decent code, and it allows great programmers to create great code (by avoiding mucho bureaucracy). If you have gurus, great! If you have just good-enough programmers, you can still use XP and get better results with them than using something like UML (in most cases).
--The basis of all love is respect
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.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
If you have a bad programmer on staff, then that's not your methodology's problem. You have HR and receuiting to fix first. Bad programmers are *never* good for the product, and they should never have been hired or kept on payroll in the first place.
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.
It is a combination of best practices, many of which will seem counterintutitive to we children of the "Mythical Man-Month," but which I have found to be remarkably powerful when used in combination.
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.
The pair programming angle is minor and unnecessary.
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.
It sounds neat, for sure, but pair programming is the one part of XP I don't buy into.
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.
I can't see any good scenarios, for me, from pair programming.[...] Maybe it would work for some people in some cases, but I can see it causing a lot more problems than it solves.
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?
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?
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.
The retcon'd reasoning behind the name is that XP is like many "Extreme" sports. Certain activities are dangerous enough that you would be loony to attempt them without taking lots of safety precautions. Things like skydiving and rock climbing (on belay) come to mind. Given that safety is such a great concern, enough practices are observed such that accidents become very, very unlikely. XP is the same way. If we are aware of how badly we may fail, and we take the same amount precaution we would with "Extreme" sports, we minimize the chance of failure while still keeping eyes on the prize.
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.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Check out this one at Information Week.
Also, a good overview of XP can be found on developerWorks.
I work for RoleModel Software (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).
You can give each other incentive to write another hundred lines of code.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I think I'd actually watch that. Put it right before or after the "The Lone Gunman" slot...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
I moderately agree with your first statements, but your last sentence kept me from modding it up (flamebait/trollish):
"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
http://www.debunkingskeptics.com/
Been reading wiki again?
-no broken link
If companies can afford two proggers at one computer, the return on their investment will likely be substantial.
Got Rhinos?
After reading about XP it looks like it was designed for people with ADHD. Or at least the practices would really help someone with ADHD cope with their problem. XP seems to really slim down the crap and let someone get to the good part while having someone keep the programmer on track. --Angus
Let's have Open Source Object-Oriented Extreme Programming!
--
I think that there are significant deterrents to successfully implementing XP in the software development field:
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.
Never been posted about on /. before, that's for sure!
http://slashdot.org/books/00/12/29/1653211.shtml
http://slashdot.org/books/01/01/30/044210.shtml
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.
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?
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!
Attention all planets of the Solar Federation! We have assumed control! - Neil Peart
How many of you actually work with people that you would WANT looking over your shoulder? My ego is huge and I'm convinced I'm one of the best programmers at my company, the are probably a handful of people you could pair me with that wouldn't slow down the process with me constantly having to explain to them all the time what I'm doing.
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.
---
https://www.accountkiller.com/removal-requested
Doors? Your offices have doors? God I wish mine did. I'd hack all night and day if I could shut out all the idiocy around me.
Steven
-- I have marked myself unwilling to moderate-- I don't have other accounts to artificially inflate the karma of
Until you piss your partner off and he decides to thwart your "style" by never using "Enter" All of a sudden your programs look like crap because it's one 50,000 character line. Who ownz who now biyatch!
Steven
-- I have marked myself unwilling to moderate-- I don't have other accounts to artificially inflate the karma of
RoleModel SofTware 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..
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.
Back in college, I did lots of projects in a "team coding" sort of way. Too bad we didn't think up the "Extreme Programming" thing and market it ourselves! Anyway, with the right partner(s) it worked great. On several projects, I had some dimwit partners, and then it was terrible. My roommate and I made a great programming team, but we didn't always work at the same time. We would brainstorm together and do some code writing together, but then I would usually do a coding spell, later (after I had gone to bed, usually) he would sit up all night, review what I had done and do some more coding. Then the next afternoon we'd sit down again and start over. So it was definitly team coding, with somebody at the computer about 12 hours a day. About 4 hours of that would overlap between us.
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!
As a developer who has worked with eXtreme Programming, I believe it to be a superior methodology for several reasons. 1) Paired programming facilitates extensiveknowledge transfer between senior and junior programmers. 2) Iterative development allows clients to be more involved in the process, allowing them to make critical changes earlier on in the process. 3) Only the components of the program specifically requested are encorporated into each iteration. Features not required for a particular iteration are not included at all. 4) Rigourous unit testing allows code to be consistently well-maintained. 5) Functional testing is also greatly emphasised. 6) Rigid, inflexible architectures are not allowed. I would encourage any IT manager on Slashdot to use this methodology for any small IT project. I truly believe it to be superior as long as the project is not too large in scope. For furher information, visit: http://extremeprogramming.org/ -Java Cowboy
This space left intentionally blank.
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...
*whup* "Get along, little electrons. Heeyah!"
I used to think that wishus was right. It's impossible to get into the zone with a pair. I generally refer to it as "flow" (cf. Mihalyi Csikszentmihalyi's various books and papers on flow). Unlike many posters claiming many things about XP we are actually doing XP here, and I have been in flow while actually pairing. It's even more effective than flowing solo. The best advice I can give is to try some of the practices. Use the ones that work. Ignore the ones that don't, but try as many of them as you can. Especially the ones that you think sound silly. XP isn't, as one person mistakenly though, a cookbook approach to development that prohibits creativity. Doing an actual XP project here, I've got better code (as demonstrated by the tests, lack of bug reports, and easy responses to feature requests) and had more fun than I've had in years.
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
--
http://www.bradheintz.com/
- updated
For one, they spend less time on Slashdot, I'm sure. Maybe that's why we all hate the idea! ;)
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.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
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.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
> 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?)
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.
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.
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
---
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