This article is about Open Source software development. Given the unrelenting ideal of better software that remains the guiding principle of the Open Source world, it is inevitable that it crosses paths with Xtreme Programming, in philosophy to a large extent and in practice to some. The author also examines some “Xtreme” influences on F/OSS development — what these are and what these can be.
Xtreme Programming and Open Source Software Development
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
In practice, XP depends on two factors quite heavily:
1) Close physical proximity.
2) Having highly skilled developers.
The fluidity and agility of XP sparkle only when you have talent and good communications.
In the open source world, the quality of developers varies greatly and does the quality and quantity of communication.
I would certainly not choose XP for a distributed project (as are many open source projects).
One might also add a third requirement for successful XP and that is 3) small teams. I’ve never seen XP work well for large teams, although some companies have come up with their own XP-like processes for large/larger teams.
All in all, I don’t believe there is any methodology that fits all projects. XP as it focuses on human skills and abilities is perhaps more philosophically aligned with open source than many other methodologies (RUP for instance). In a practical sense, one should choose a methodology based on the project type and the players involved. XP is no panacea.
i wrote a research paper for a senior computer science class on this subject last week hehe. these two methods are great development techniques for software engineering. the use of these techniques yields better quality code that is more reliable and less prone to bugs with the number of eyes prying over the source code. as we know with some proprietary systems *cough* windows, these methods of software development would be an improvement to decrease their track record of software security related issues
Don’t the developers need to be close to each other. How does that work when they’re spread out across the globe??
The fluidity and agility of XP sparkle only when you have talent and good communications.
And that is a unique aspect of XP, is it? – that it only works when the developers are tallented and good communicators?
Question: ever seen much emerge from a project populated by 3rd rate programmers who can’t communicate? Look at the dead project rate at Sourceforge.
In the open source world, the quality of developers varies greatly and does the quality and quantity of communication.
Wanna know something? This is also true in the commercial software world. In fact one could argue that the standard on most FOSS projects is higher, since the programmers are self selecting. There are plenty of employee “developers” who sit in corners exuding bad attitude and surfing web the whole day, not to mention the “but I’ve never done that before …” brigade who think their deep knowledge of VB version 1.0 is a guarantee of a job for life.
I would certainly not choose XP for a distributed project (as are many open source projects).
And you would choose instead …?
Look, don’t fall into this excluded middle error: Some things in XP are harder in distributed FOSS than for the mythical perfectly funded commercial project – “therefore” we cant’ use it at all.
Whilst some aspects of XP aren’t perfectly sympathetic to distributed development, those problems can be overcome with sufficient effort, imagination and technology – mailing lists, IRC, regular on-line meetings. Even distributed pair programming can be conducted via IM and desktop sharing.
For many FOSS projects, access to the customer is a great deal easier than for commercial XP proejcts. Try getting a $400K p/a lawyer to sit in a room of developers for 6 months. In FOSS, customers are often attracted to participate in the development process because of the release early concept gives them something they can use and see potential in developing earlier.
Similarly there is no reason why agile techniques such as test driven development can’t be used with great success in FOSS. Its a great way to bring less experienced programmers into productive work.
Microsoft’s security problems are not bugs. They are purposefully built back-doors so that your system can be broken into at any time by Microsoft and law enforcement.
Yeah, right.
Actually law enforcement has a device called a “warrant” that lets them get into your computer, even when it’s turned off and M$ were so anxious to snoop on customers that they “built-in” not one back-door but about 652 of them ( and counting). Only the paranoid …
You forget the international aspect of the Internet. US law enforcement would have a really hard time asking for a warrant to even entering my house, let alone seizing my computer. And there is no way they would get my crypto passphrases. No warrant, even a Brazilian one, could grant them that. So, if they want to mess with my computer, they have only the option of going for a backdoor in Windows. And there are a lot of those, I assure you. Net result: I don’t touch Windows with a ten foot pole. Even though I have nothing to hide from them for now — everybody in the Net knows I loathe GWB.
I agree with one of the commenters on that Freshmeat article. XP is a process meant to maximize time coding and minimize time doing anything else (planning, engineering, etc.), because programmers notoriously hate that stuff. It is a process that works for people who like to code “just for the sake of coding,” and fails miserably for those who have other outlooks.
I’ve never tried it (don’t knock it till you’ve tried it!), but I imagine it would fail miserably for me. I like to chart things out before I start coding–understand the architecture of the existing system before I plug in my piece. XP, if abused, seems like it could encourage hack upon hack upon hack. One of the reasons it’s particularly unappealing is that though I enjoy working on software projects, I personally hate long stretches of coding, especially when that coding is mainly trying different things “until it works.” Whenever I fall into that trap, I realize how a little time sitting back and reflecting on the problem could have solved it in an easier and less stressful way.
I guess what I’m saying is, to each his own, but make sure you don’t shove a programming methodology down a programmer’s throat. That is, if I were a manager of an XP development team, I’d make sure that the only programmers working there are the ones who feel they can work best under XP conditions–namely, people who just like the constant sound of their fingers deterioating on their tactile keyboards 😉 Nah, that’s a little mean, especially after such a long comment 😉
In practice, XP depends on two factors quite heavily:
…
2) Having highly skilled developers.
In my experience I’ve found that if members of the team are at different levels then those with less experience gain immensely from working alongside their more experienced colleagues. XP is a great way of getting everyone on similar levels. On the other hand the more experienced developers can get extremely frustrated at being held back.
The problem with XP is that is does have a number of disadvantages, so careful consideration needs to be taken before deciding whether to use XP within a project.
umm. B-slap-the-E again you are wrong.
1) look at subethaedit formally known as hydraedit. it makes use of IM and revision highlighting. you could be across the world from each other and be very productive in almost any language.
2) a mix of skill level is the best thing because then you don’t get 5 highly skilled programmers arguing about implementation, rather having one good programmer, and some intermediate programmers and a novice are the best option. it makes the higher level developers better though explaining and teaching, and it makes the less experienced developers better because they are learning. as long as the project manager delegates correctly, there is not going to be any problems. the best situation would be for the most experienced programmer to look over the work and bring any problems to the attention of the author and show him/her why it was wrong and how he/she should fix it.
a mix of skill level is the best thing because then you don’t get 5 highly skilled programmers arguing about implementation
So you’d prefer 5 less than highly skilled programmers arguing about implementation?
Read this to know why:
http://martinfowler.com/articles/designDead.html
http://www.agilealliance.org/
http://agilemovement.it/index.php?newlang=eng
you obviously can’t READ. try reading again with special attention to what I actually say.
a mix of skill level is the best thing because then you don’t get 5 highly skilled programmers arguing about implementation
So you’d prefer 5 less than highly skilled programmers arguing about implementation?
You can’t get 5 highly skilled programmers argue over the implementation! It is easy to get two highly skilled developers disagree, but when you got 5 of them they usually end up in groups of 3 vs 2.
Having learned XP directly from the inventors, their experience has shown direct physical proximity is important. You do not get the same effect working online whatever tools you are using. The various other studies on pair programming have also shown that you need the communication and connection that comes from getting to know someone in the real world, not in the virtual world.
Again, from the XP experts and their experience: the more skilled your developers, the smoother your XP project goes. Of course you can start out with less skilled developers, but then there is a ramp as they get up to speed. There is no free lunch, not with XP or any other methodology. Trust in the programming world, as in the real world, comes from character and competence. The more skilled the developers, the easier it is for trust to develop as the competence is already established. Character is able to be assessed and adjusted to in the real world much faster than in the virtual world.
Debman, your lack of real world experience and education regarding XP is telling. Have you ever worked in software?
I did “XP” once…although it wasn’t called that. It helped a lot, mostly because I couldn’t get distracted and start web surfing, checking email etc. Not really because we were catching each others errors etc
Although we didn’t embrace the whole XP thing at my job, me and a colleague decided to try pair programming. It was very interesting, first to keep us focused, as you said, and also because while you’re discussing with your colleague why do “a” and not “b” you always end up thinking more deeply about your algorithm instead of just going for the first idea.
Another good thing is the instant code-review and quality check given by the other guy.
It’s also very good for motivation, usually when one of us get frustrated with some problem the other guy keep pushing or take over the keyboard to try something.
At the end of our experience we found out that the productivity of pair programming was quite similar to 2 guys doing single-programming, at least for us. Not to mention the extra benefit that both of us knew the whole system, instead of “this is my part/this is your part”
well, I am thinking from the educator’s prospective about the mixture of experience (group learning is a much better method of teaching than lecture)
but you are right, after some thought about it, proximity makes more sense because as some have just said, it keeps you on task and the instant feedback and physical presence of the other programmers make for better brain storming/problem solving.
I have to agree with Rob, pair programming is great for motivation. It is much harder to get stuck staring at the blinking cursor while deciding what to do next or to goof off reading email or Slashdot while you have another person with you. It tends to keep both of you busy.
On the downside, for the programmer not at the keyboard it can be very hard to follow what the guy typing is doing, especially when they are using vi. The cursor jumps around and things change while you have no idea what they just did. Also, the programmer without the keyboard can feel useless because all they are doing is watching. I find having a laptop for the second guy is helpful. He can use it to make notes or explore documentation or try out ideas when he’s bored watching what the first guy is doing.
XP assumes a close, cohesive group, with daily stand up meetings, and a customer that is part of the team and determines the stories.
Open source projects are very loose, completely chaotic with people coming and going, and there usually is no customer to determine the stories.
Maybe there are some ideas to borrow, like “write the test first”, but that’s about as far as it goes, IMO.
Marc
I’ve found this interesting:
http://c2.com/cgi/wiki?OpenSourceAsAgileProcess