The things that I remember XP being <i>controversial</i> for were pair programming and TDD - real TDD, where you write the tests first and let the tests drive the design. And those are the two things that I don't really see as having caught on.<p>I mean, pairing is a fine approach when training someone up on a codebase, but it tends to be much more effortful for the guy in the driving seat, while the guy looking over your shoulder is making small comments and doing researchy lookups. This makes it less than efficient when both people are at the same knowledge level. The extra eyes looking for bugs is debatable; the bugs are more thoroughly found with tests.<p>Test-first TDD is even less popular. Norvig vs Jeffries was enlightening - <a href="http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/" rel="nofollow">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/</a> .<p>Software does have a much heavier focus on testing than it used to, to the point that in many projects, everything is implemented twice - all features have two representations, one in the form of the implementation, another in the form of tests, and often with the lines of test code outnumbering the implementation.<p>But other things have suffered IMHO; making code easy to test tends to over-abstract it, making it more parameterized and exposing more implementation details of high-level abstractions.<p>APIs are often uglier with a lot more exposed symbols to handle the parameterization, with various bits and bobs asking for interfaces that only have one concrete implementation that can only be created by a factory, and you have to learn the knack of actually instantiating the useful bits anew for each library. I've got Java squarely in mind, of course, and I'm convinced better language design can solve the problem with less harm to the software.
In regards to pair programming - I realized recently that I'm opposed to it just because I don't enjoy it. I don't like having someone look over your shoulder while programming, or looking over someone else's shoulder while they are programming. It is exhausting. Collaborating in front of a whiteboard for a few hours is fine - I just don't want to do it all day. I also don't like feeling guilty taking a 5 minute break to read hacker news, or my personal email.<p>And I'm in the programming industry because I enjoy programming, so would want to work in an environment which I enjoy - and in today's market, i have the luxury of picking my employer.<p>I'm sure not everyone feels the same way, but I suspect I'm not alone in that opinion.
Putting my headphones in, drifting in my own, private world of code is to me one of the simple pleasures of life. Ok with short meetings and thight, small schedules and the like, but put someone watching at my screen while I'm coding and I can easily commit an homicide.
The XP book was hugely important for me. I read Kent Beck's article on Extreme Programming in IEEE Software in October 1999, and got the book as soon as it came out.
For the first time I saw a methodology that reflected how I actually liked to work. I hadn't done pair-programming then, but working in small increments, with lots of tests, rewriting etc - more agile in short. Previously, I wrote programs <i>despite</i> the methodology (like RUP, or company internal methodologies), but here was a system that actually helped. Truly revolutionary at the time.
Another post saying nothing by uncle Bob. His ability to say nothing never ceases to amaze me -_-.<p>He's one of the good guys, that's for sure - but every time I read his blog I keep waiting for that something new and it never comes.
In the short section entitled "Success" toward the end of the article, the author repeats the sentence "Extreme Programming succeeded" five times, slightly rephrased each time. To be perfectly honest, I find it hard to comment on this without sounding derisive. There is no hint at what "succeeding" even means for a software methodology, and even if we assume we know what "succeeding" means in this context, there is not a shred of evidence for the truth of the statement. A poorly defined statement repeated five times without evidence or proof.
It's still relevant - I doubt that 2% of teams do all 12 (mostly it's the pair programming) but it is without a doubt the seminal work on software in business of the last 15 years.
I love pair programming. Frankly though, it takes several hours of committed time to be really useful. It's hard to get two production programmers to sit down together for a few hours to focus on this. To get around the time hurdle, I've proven to upper mgmt that the amount of bug fixes or efficiency improvements is easily greater than the amount of product the two alone could have achieved. There's a Tesla-ish resonance that occurs when two people are focusing on the exact same problem. LOVE IT.
The Ten Year Agile Retrospective:
<a href="http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).a...</a><p>From June 2011, this article covers four key success factors for the next 10 years of agile. Great thinking on software development.
I was developing software back then when extreme programming came about. It wasn't controversial at all. In fact, everyone I knew thought it was a much better way of programming than the current waterfall method. The only problem was inertia from management, which is always the case.
I like a lot of what XP brought to the table, except pair programming. I find it's genuinely not effective most of the time. It <i>is</i> very effective when teaching someone. But in general I have found it to be slower, produce worse code, reduce accountability, and causes frustration. I'm currently working on a long blog post detailing my thoughts on it.
I was pretty shocked to see a programmer that delusional about XP and its influence. Then I got to the bottom and saw it was an XP snake-oil salesman writing it, not a programmer. Surprise. All 12 of those things predate XP, and most of the 12 things are situational. There is virtually never a case where following all 12 of those things makes sense. But that is exactly what XP was. It demanded you do all 12. Just saying "because some people still do some things in that list, XP mattered" when those things were being done before XP came out is absurd. "Which ones don't you do?", all of them but avoiding overtiming.