Beck and Andres on Extreme Programming

narramissic writes "In recent years, Extreme Programming (XP) has come of age. Its principles of transparency, trust and accountability represent a change of context that is good not only for software development but for everyone involved in the process. In this interview, Kent Beck and Cynthia Andres, co-authors of 'Extreme Programming Explained: Embrace Change,' discuss how XP makes improvement possible."

Extreme...

I was hoping for something a little closer to Extreme Ironing. [extremeironing.com]

That would have been cool.

Article's dated 6th May 2005....

This is too extreme even for slashdot...

Overrated

In my opinion, extreme programming is extremely overrated. Some of the ideas, such as test-driven development (although this concept is not restricted to XP), work well. Others, such as pair programming just do not work in my opinion. Programmersare solo beasts - putting two of these dragons behind one keyboard is asking for trouble.

Re:Overrated

I worked under it for at least a year. Its another one of those methods that looks good on paper, but sucks in practicality. What's unpracticle?

1. No company in their right minds wants to pay for TWO programmers to do a single job. But then, again, you can always get 2 programmers at half-price to do the job (and have half the quality of one full price programmer).

2. As with any other method, it assumes all the specs and implementation have been worked out before the code is even written....nobody has the freedom to write experimental throwaway code to even see if their approach is even feasible in the coding, or, if programming a device, if the device will even work with the approach being made (for you people not in the embedded world, most device datasheets are incorrect and seldom get corrected).

3. While its great at letting the mundane functions be rewritten (refactored) as many times as possible, it gives a mechanism where newer features are *always* put off (by managers usually) indefinitely....its an illusion, under a few managers, that the programmers will ever get to implement the newer features wanted by customers (its amazing how most new features are always rated as low priority by someone other than the customer....even more amazing about how many 'stories' aren't written by the customer.).

4. Even in the XP books it is explained that XP is not meant to work for every single software environment/situation....yet there are managers who will do their best to try to force it to work when it won't.

I always find it really is better for a group of Programmer Peers to sit down together and review the code AFTER it has been written (with tests). Trouble is, most companies/managers refuse to understand that 'Programming Peers' do not include the stock boy in shipping.

Just my $.02. Can you tell I didn't really like being under the XP model myself?

Re:Overrated

Your post reads like a summary of the book, "Extreme Programming Refactored: The Case Against XP," by Stephens and Rosenberg I recommend it for everyone, including people who are using XP successfully.

If nothing else, it's worth it just for the song lyrics:

Eight Builds a Week

(Sing to the tune of "Eight Days a Week" by The Beatles)

Livin' in a timebox
Guess you know it's rough
Gotta build every day, babe
Even half-baked stuff

Build it, ship it
Build it, ship it

Ain't got time for design, babe
Eight builds a week

Build it every day, babe
Build it right on time
One thing I can say, babe
No time for design

Refactor it, test it
Build it, ship it
Ain't got time for design, babe
Eight builds a week

Re:Overrated

Others, such as pair programming just do not work in my opinion. Programmersare solo beasts - putting two of these dragons behind one keyboard is asking for trouble.

Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer. Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.

But when you put two programmers with equal authority, you have one thinking about the bigger picture and the other reviewing his mind flow. At the same time the later is writing down the ideas in code, with the first one reviewing his code as he types.

Programmersare solo beasts

Where have you been the last 20 years? The stereotypical programmer, hacking his piece of kernel over night is very endangered species, and rightly so. Like any kind of engineering, software engineering needs as much face to face collaboration as possible.

Re:Overrated

You really think XP is Engineering?

It's an attempt to achieve a greater level of quality through process/practices, which is as close as "software engineering" has gotten to real engineering so far. Arguably, though, "software engineering" isn't real engineering until you use formal methods to ensure the correctness of your design and implementation.

Re:Overrated

Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer. Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.

I've never seen one of those. Every code review I've participated in has been a collaborative effort between peers. If you treat a code review as a cooperative effort between programmers, it doesn't have to be frustrating.

Like any kind of engineering, software engineering needs as much face to face collaboration as possible.

To a point. But real engineering requires planning and clear interface definitions, and XP -- almost to the point of being pathological -- attempts to avoid planning as much as possible by subsitituting endless chatter and tremendous time wasting repeatedly reimplementing what could have been done right the first time. (And yes, I know some things always have to be reimplemented, but just because mistakes are inevitable doesn't mean they have to be encouraged.)

Software development has an unfortunate tendency towards fanatical adherence to the latest silver bullet. Usually, this involves an implementation language backed by a marketing push; XP seems to be the first programming fad built entirely on book publishing. But then, no implementation language ever actively encouraged the kind of passive-aggressive personality that thrives on XP.

Re:Overrated

I found pair programming to be very efficient. But it depends on how you pair people.

(Summary of my best practices article [mobydisk.com])

Junior developer alone: Can complete the project but with errors a senior developer could have fixed. Code reviews fix this, but are tedious.
Senior developer alone: Good code, but this tends to breed "cowboy coders" and doesn't pass on knowledge.
Senior + Junior: Highly effective, but only if the Junior developer is the one at the keyboard.

Other combinations can help, but aren't superb. I recommend pair programming (1) on tedious code, (2) to spread knowledge, and (3) when refactoring something crucial.

buzzwords

agile approaches, agile software development in project management movement, open and honest communications
So what's this about, apart from the management-speak?
I feel like I read half dozen pages with barely any content.

Re:buzzwords

I view XP as a methodology to solve a major problem I've seen in software - communication.

Why do we build software? It's to provide value for our customer, whether that customer be a marketing department, a gamer, or ourselves. And if we don't keep in touch with what it is that they want (recognizing that people generally don't know what they want until they see it), we probably won't provide the value we could.

To that end, XP encourages constant communication by using frequent releases of the stories (read: features) the customer thinks are most valuable. The customer gets a working version every week, or month, or 2 months, or whatever cycle seems to work for the team.

From the development side, XP encourages the code to always be potentially shippable by having a suite of Unit and Acceptance tests (the former written by the developer /before/ the code is written, the latter written by the customer(!)). We continually run them using a Continuous Integration server which monitors the code repository and checks out the latest version, notifying the team of any conflicts.

It also encourages things like Collective Ownership, where, in theory, any developer can sit down and work on any part of the system. This is achieved partly through the unit test suite, and partly through pair programming with frequent swapping (we swap pairs generally twice a day, in the morning and at lunch, but some teams do more, and some do less).

But, regardless of all the practices (and there's more than I'm listing above), the end goal is /not/ to be "XP", it's to deliver value to the customer. And if your current practices are doing that, then that's what is important.

As far as TDD, I have a series I recently did which shows how TDD works here (part 1) [cornetdesign.com] and here (part 2) [cornetdesign.com].

Unfortunate name

Its principles of transparency, trust and accountability

I find this funny as the programming behind Windows XP relate to none of these.

XP = Extreme PR

Thank goodness Slashdot's there to help publicise not only ground breaking new books, but even new editions. I really wouldn't want to miss the opportunity to discover why I need to buy book v2.0.
Does anyone remember when Slashdot wasn't quite so heavily infected by the insideous PR virus?

"Extreme" Programming

http://developers.slashdot.org/article.pl?sid=01/0 4/03/1633250&mode=thread [slashdot.org]

Laundry?

FTA:

I think that the first book was in reaction to a culture for programmers that was basically camping in their cubicles in Silicon Valley where people were spending their entire lives living out of cubicles with food brought in and laundry taken out.

There are places where they take out laundry? Real programmers don't change their clothes until the job's done!

Why is it called "Extreme"?

To me, the word "extreme" sounds like they program in assembly 24x7 for one week straight, or they program with laptops, while running away from a pack of wolves or something. But apparently it's not like that. So what makes it so "extreme"? Did they come up with that name when they were discussing their interests with their jock-friends?

"Oh yeah, I'm in to pretty extreme things. Currently I'm doing base-jumping and ultimate-fighting. How about you?"
"Well.... uh.... I'm in to.... EXTREME programming"
"Whoa! Radical!"

Re:Why is it called "Extreme"?

It's called Extreme because they take some basically good ideas and push them to such extremes as to be completely useless in the real world.

One of the best quotes ever...

Kent Beck hits the proverbial nail on the head with this zinger (which I'm sure is certain to stir up quite a few):

"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled. I used to say often that programmers were children. They liked not to be yelled at and to have more toys ... I think programmers are, or at least can be, adults and can and should, for the good of development and themselves, act that way."

The above quote sums up almost every problem that I have seen over the past 10 years with the various development shops I've been a part of.

Is he a manager ?

Because all the programmer I know around are quite adult, responsible, and do not care for the latest toy. But they do care that they are given enough time to implement features, taht the features are correctly documented, that the spec are there etc... And in the last 6 years I was there, those point were not met, and usually the manager were responsible for a reason or another, but never beared the responsability.

To sum up, to define the programmer as "child", is really disapparging, and far far away from reality of the average software developpement shop. Most are average guys which want to do a correct job, but are put in impossible situation by management.

No if the quote would be applied to manager "manager are like child, they like to play and win, but do not wish any responsasbility in tehir action".

Re:Is he a manager ?

Beck is not a manager. That doesn't mean he lacks management skills (I've seen evidence that he does have excellent management skills) but reflects his hands-on nature. He writes code, and thinks about the process of writing code. And his thoughts tend to be somewhat broader than most peoples, and more complete, and when he shares them with others, better expressed.

In other words, find books and papers and software written by Kent Beck and read the lot. If every programmer on the planet did that, even if they disagreed with everything he'd said, the IT industry would become immensely more efficient and effective overnight.

Now consider Beck's quote that you have taken affront from. Think about new programmers, software heroes, cowboys, even experienced and capable programmers - they all want more toys, to be left alone to get on with their job (which they perceive as programming), that everything is handed to them on a plate. Your comment even reflects that - "enough time", "features are correctly documented", "spec".

Real life isn't like that. And instead of whining about it, Beck stepped back and re-evaluated how to approach software so that he could deal with those issues, and still write top quality code, and still meet deadlines and give the customer value.

No, Beck isn't a manager. He's quite beyond such limiting labels.

Not Extreme

If it doesn't involve fire or razorblades it's not extreme. I hate the way the word has lost it's meaning these days...

Never...

Xtreme Programming: Never have so many invested so much on a proposition backed by so little evidence.

Real Extreme Programming

IMO real extreme programming should involve at least 3 of the following:

1. Only having 24 hours to deliver the code
2. Failing would cause thousands of innocent people to die
3. Getting your interface specs from a dieing man after being helicoptered across town
4. Using emacs
5. Failing code review results in you and/or your spouse being shot in the leg

This article is rubbish

Although I am a proponent of some XP concepts and feel certain concepts can help with software quality and delivery time, this article does not highlight any of them. This article is nothing more than "blah blah blah, XP is great, now go and buy my book". How on earth did the editors let this one in.

Write the test first

I don't understand this. You write the test before you write the code? This doesn't work in real life because, as every experienced coder will know, the goal posts get shifted at the last moment, usually a week before the product's supposed to go live.

Re:Write the test first

Hmm. For the definitive description, I can only suggest you acquire (beg, borrow, buy, etc) a copy of Test Driven Development by (eek) Kent Beck.

My brief summary:
You write a test. To write the test you must know what it is you are testing. This means you have to think about interface, so you can access the functionality, and function, so you know what it's meant to do.

Thus before you've written any code you're already putting a lot of thought into what's going on with your code. Far more thought than most programmers put in (trust me, I've worked with too many ;)

To be able to write a test with small enough scope (so you don't end up testing half the system - you may want to do that, but not right now) you need to be able to isolate the piece of code you're testing. There are multiple mechanisms to achieve this (see the paper "Endo-Testing: Unit Testing with Mock Objects" for an example) but the outcome is this: The code you write, to pass your test, can be isolated from the rest of the codebase. It is inherently decoupled (at least to a degree).

Now extrapolate this across the entire codebase. It's all decoupled. It has to be, so that you can test it all in isolation.

That makes the code easier to re-use too. If a block of code isn't tightly coupled to the things that use it, or to the things it uses, it's easier to re-use with other things.

Which leads to the other aspect of TDD: Eliminate duplication. If you're doing TDD by the book, you ruthlessly excise any duplication in your code. Where you see two blocks of code doing the same thing you refactor them into one block of code.

This is relatively risk-free, because all the code you're changing has a full suite of automated unit tests. Which you're running every few minutes (because they take a couple of seconds to run). So you're getting pretty prompt feedback on any errors you accidentally introduce while changing the code.

Of course, you have a lot of test cases now. These are a form of documentation. They provide examples of how to use your code, and also pretty definitive indications of how it's expected to work.

So the process of writing tests forces you to write testable code. I believe testable code shares many characteristics with well designed code.

You may also want to pick up Michael Feather's book on "Working Effectively with Legacy Code". Many of his techniques revolve around building test cases, and refactoring the code to make it more testable. That's not coincidence (and remember - refactoring means "improving the design of existing code").

As I said, I'm an amateur at explaining this compared to Beck, so find a copy of his book and read through it - it's actually not a long read, the basics really are simple.

Looks like Standard Concept..... however

It looks like it's had the curse of consultants beat it down with their theory and "improvements"

XP vs XO

Personaly I miss the days of eXtreme Obfuscation, when multi-year projects, even entire careers, could be made of producing and deciphering intentionally and inadvertantly obfuscated code. Especially when you really had to dig through 4 foot high stacks of 14 7/8 x 11 green bar source listings and associated core dumps just to figure out that some asshole was relocating buffers on a vector just to fsck with the person coming along behind him.

Point out major successes

Perhaps XP should point out a few outstanding successes instead of perpetual promising of improvement. So far, in my experience, the net result is pretty abysmal performance and several extreme failures.

Stop the X!

This eXtreme-whatever fashion really has to end. It's just the new buzzword, but it has been way to far this time. Everything from candy and books to programming and movies are X.

We don't need EXTREME things, why don't you try with creative, different, innovative things?
People lives such boring lifes, and they have been buying shit for so many years that all the usual lies used to sell are not longer valid, so we have to go the the limits, THIS time there really is something new!. Bullshit.

All this stuff is the Paulo Coelho of Programming. Bullshit literature for those not manly enough to just code C/C++/Perl/Python/PHP. This are real languages, and they have all we need. But we are in the reign of Coelho's bullshit books; and so, something being just good is not enough anymore. It has to be different to everything else in every way possible, it needs shinny mirrors all over it, and it needs to be easy, it must "change your life", and "take you to new levels".

I'm tired of this world, that's why i don't live in it.

Treat programmers like other professionals!

"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled."

As a programmer, I agree 100%. I expect to work and be treated like any other professional.

NOT as a lab rat for "extreme programming" or whatever buzzword-laden feelgood bullshit management scheme comes along this week.

You wouldn't go to a painter and say "I want you to make me a painting. It doesn't matter what it consists of yet, we'll worry about that later. Just start out with a box or something and we'll meet every day and figure it out from there. And just to make damn sure you can't get anything done, I've hired another painter whose role is to sit around and annoy you." So why does that make sense for programmers?

Re:Treat programmers like other professionals!

Amen to that, brother!

First there was the "cat herder" motif. Programmer's are savage animals to be herded about by sensible managers, since they are wild and unpredictable and can't possibly function in a professional manner. That didn't go down too well, so after that programmers are this special breed that must be protected from the evil clutches of managers, like an artist on a quest trying to get rid of those pesky debt collectors. Nope, didn't work either. So now programmers are, really, nothing special, *bemused chuckle*, so they must work in pairs because they really can't discipline themselves all that much, so can't follow deadlines and schedules and program their work accordingly (pun intended).

Really, wtf?!? Who comes up with this shite!?!

I'm a professional. I study. I work. I have to deal with clients and managers and other programmers and emails and schedules and deadlines and projects and planning and meetings and $"#%$$ hard disk failures and stupid IDEs and dumb APIs and idiotic OSs and back pain from lugging the laptop around and hand pain from sitting on %$#"%$$% chairs with %&#%#$ desks and &%%"% mice and #$£&% keyboards and procrastination and bills and everything else one has to deal with in any job. And above all of this I still love the job, so I have the extra duty of being wacky some of the time just to fulfill my geek quota.

And besides all of this, because I have this label someone stuck on my back somewhere without me noticing, announcing to the world that I'm a programmer, I have to also be a "lab rat [so aptly put by the parent, which is why I'm shamelessly quoting] for whatever buzzword-laden feelgood bullshit management scheme comes along this week" (or the next... and the next...), because someone is bound to read that buzzword-laden $#&%$%# and decide it would be so much more better amazing wonderful wow to make me work like the aforementioned buzzword-laden recommends as the oh so bestest way to get anything done with those darned critters^H^H^H^H^H^H^H^Hprogrammers!

Could you buzzword-writing freaks, like, go pester the street vendors or accountants or something? I really need to finish these project design reports so I can start implementing the architecture I designed together with my team on - *gasp* - separate computers.

GUI prototyping tool

There is also one good tool called Petra supporting extreme programming prototyping http://petra.cleverlance.com/ [cleverlance.com] We use it and love it.

Who uses XP anymore?

Most people have moved onto other agile methods like SCRUM. XP had a lot of hype, by its authors mainly, and now many of its techniques have proven to unusable and have no value. I know of at least 1 300 billion dollar company that tried it and left it behind because it was wasteful in many ways.

Agile Programming == Late night infomercial

Agile Programming is like a late night infomercial without the "these results are not typical" disclaimer.

The real problem is getting a cohesive team

Taken as is, XP can work very well - for teams that are already strongly of that mindset.

However, typical development teams are not staffed by management based upon styles, ideologies, or personalities. It is often by things such as where they sit (seriously) and whether or not they just finished something. A group of 5 "resources" are put together and told to work. If you take 5 random people and try to get them to use XP well, I can pretty much guarantee things won't work terribly well. To be fair, any process is going to have trouble with the typical staffing methodology prevalent in the marketplace.

If you get a bunch of people who lean towards the XP style, use XP. Great. If not, use a different model. Tailor your process to the people. A process can be changed easily, people's personalities can not.

Extreme Hogwash

First a disclaimer: I worked on an ADP project that involved Intelliware [intelliware.ca] - an XP shop to build a mutual fund prospectus preprinting system (system that collected information from different mutual fund vendors, and used customer information to decide what and when to print and to mail to that customer.) This was a second iteration of the project. The first iteration had to be scrapped, because the same vendor provided a solution that did not scale to the task, when major Canadian banks came online.

My impression from the entire excercise, (which included daily standup meetings, story cards, paired programming, unit testing, end of the day documentation.) The process became very very wasteful. I personally saw that putting 2 contractor programmers, each at 90/hr at one workstation does generate dialog between the programmer, where both have to generally agree on the approach to any given problem but I did not see any performance improvement achieved by this approach over havin one 90/hr contractor doing the same thing. Since the requirements of the system were still being 'refined' and since there still were deadlines to achieve, the pair had to produce as much code as possible in a very short time period and various bugs still slipped through the process (most of which admittedly were caught by the unit testing, but unit testing.)

The daily standup meetings were mandatory of-course even though most people loathed those. There still were 'overal architects' on the process, and due to the politics of this specific vendor they forced a custom server solution upon the customer (even amid my vivid objections. I was trying to get the vendor to use existing server and framework solutions, unfortunately my voice was not heard, there was no will to prevent the imminent demise of the project by concentrating on the problem at hand and not getting ourselves into a proprietary application server territory.)

Basically the project was not delivered on time (and as I at the time predicted) went over the original time estimates by about a year. I was forced to leave 3 months into the project because I became to frank with the department director. 3 months after I left, Intelliware was forced out the door as well. The project was partially delivered within the time that I estimated, the department director had to leave the department as well.

I do not get any warm and fuzzy feelings about anyone promoting XP, I right away start looking for ulterior motivations. My personal feeling is that people who do not want to carry any responsibility for the project, for the code, for the requirements welcome XP (or can be easily swayed to accept that methodology.)

In XP noone is really personally responsible for anything, and that attracts people who want to have it easy. Documentation is shunned upon, any forward thinking is met with contempt. Any questioning of the process/methodology is considered a heretic. Sweat shop mentality dominates XP, and it is not surprising, considering that it takes 2x as many people to deliver the same solution for 2x the money. Obviously there is a drive for those, who are actually producing code to work as fast as possible without any room for thought.

I did however find that unit testing is a very good approach to testing and that wiki style documentation is excellent if used properly.

Re:Extreme Hogwash

That doesn't sound like an XP project to me at all. How do you go over by a year if you deliver every 2-6 weeks? - you didn't read it, did you? For various political reasons instead of just concentrating on business at hand, the abovementioned firm decided to write everything you can find in a commodity application server by hand. My estimates included this fact, the XP provider who I named convinced the client that everything will be done by the client's deadline (about 4 months after the project began.)

Delivery of various pieces was done every 2-4 weeks actually, but the application server part feature creep that was unapparent to the client but obvious to me reared its ugly head. Every time a piece of code was 'delivered', it became apparent that it had to do more and more, and every time it had to be redone.

My point is that XP provides excellent conditions for this kind of 'delivery' mechanism because it objects to doing any real architecture (analysis of the requirements and features upfront.)

That's ludicrous. One key tenet of XP is "sustainable pace". Don't burn out, don't work late nights. - there was almost no late nights, but everyone got the CTS. One person at the computer had to provide the code that two people would generally provide during the day.

You are aware of the body of evidence (academic and business) that shows that while pair programming is less efficient than solo programming (in a lines of code delivered sense) it is nowhere near twice as slow and the code delivered is so considerably higher quality that it more than makes up for the overhead? - I am aware of my own experiences and I don't have to submit my experiences to any 'body of evidence' (academic or business.) XP forces the pair to provide similar amount of work as if they were working seperately.

I call bullshit on your statement you were using XP. You may have used many of the practices, and you may have called it XP, but you didn't do it. - you can call it whatever you want, Intelliware is the top XP solution provider in Ontario.

Don't feel bad - it's a bloody difficult thing to do properly. Possibly too difficult. By far the highest discipline method I've ever used. But don't badmouth it just because the company employing you didn't do it properly. - First of all, I was a contractor for ADP, and Intelliware was an outside resource, but all (4) ADP people were put into Intelliware teams and we had to work together, so I wasn't employed by an XP company.

Secondly, what I am feeling from you is exactly the same attitude that I was getting from that XP shop - do not badmouth XP. XP cannot be wrong. I am under impression that XP is a religious movement rather than a management solution to a technical/management/social problem.

The fact that so often you can hear people say exactly this: it's bloody difficult thing to do properly, should be a red flag - it is just like any other methodology or any other process. Anything is difficult to do properly and in theory anything will work well if done properly.

Give me a bloody break, just because you bought into the entire XP religious propaganda, doesn't make XP any more valuable a tool than any other methodology, process or a combination of requirement/design/development standards.

XP makes improvement possible?

So, no improvement ever happens without XP? Somehow, I doubt that.

I think this goes beyond "extreme" to "hyperbolic".

Mostly, XP improves Kent Beck's net worth ...

Having been through employers who tried both XP and Scrum (not Beck but similar), the only positive thing I have to say about either is that if your developers really suck, teaching them XP and/or Scrum will allow you to keep much closer tabs on their lack of progress. Otherwise, like most "new" methodologes, it's a way for people to teach classes and sell books.

extreme-ly lame

"Extreme" has lost its meaning in the same way that "Alternative" has. And pair-programming has always been eighth-grade gay, no matter what anyone says.

Test-first? Yeah, sounds great on paper. In reality, it gets steamrollered by feature requests. And besides, no one really cares if the software works or not, because if it doesn't, it just gives the user an excuse to not work for the whole day, or to take an early 3-day weekend. (at least for most software. the statement probably doesn't hold for users of medical or avionics software.)

The current state of programming is more like finger-painting than engineering. It's messy, hands-on, and only a mother could love the results. And it is performed by children dressed up in the bodies of adults.

The solution? Simple. We only need to be just clever enough to figure out how to implement AI. Then we can let the machines take over. Let *them* figure out all the hard stuff, so we can get back to playing WoW. And I for one will welcome our new programming overlords.

XP in the University

I enjoyed XP while working at school until I realized that they were just using me to get good grades. Putting it the workplace gives way for the unresponsible to jump on the coat-tails of the responsible.

An observation about XP

I worked on an XP project a couple of years ago. Towards the end of my involvement, i found a quote that summed up the XP experience:

Weeks of programming can save hours of planning

XP certainly does make improvement possible.

It shows people why they should use Linux or OS X.

duks

Re:"XP makes improvement possible"

*skims article*

XP blah blah trust blah improvement blah Embrace blah

*kicks in knee-jerk anti-M$ flame*