8 ms·

Extreme Programming, a Reflection

99 points by joseph_cooney 13y ago

henrik_w 13y ago
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 despite the methodology (like RUP, or company internal methodologies), but here was a system that actually helped. Truly revolutionary at the time.
- ollysb 13y ago
  The strange thing is that this is how everyone begins to program you write a little code and get something working. Then you add a little more, reorganise things a little and keep going. It's a natural process that somehow gets trained out of us in CS courses. We're taught how to plan a whole system and them build it. Long running projects interacting with an infathomonable number of users put paid to that though. I think the thing extreme programming got most right is that software is about people. Telling the computer what to do is the easy bit. Figuring out what the users want them to do is the hard part.
  - henrik_w 13y ago
    Exactly. You grow software. I really like this quote (by John Gall): "A complex system that works is invariably found to have evolved from a simple system that worked."
  - discreteevent 13y ago
    The main thing for me is that its virtually impossible to build a complex system (essentially complex that is) without having good feedback and then adjusting the design to fit. That feedback comes from testing, review and the customer. The shorter the feedback cycle the quicker you settle on the target. The XP book helped spur this on in an age where a lot of people had lost the run of themselves. However these ideas were around and practiced since software development started: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it... And before that for other activities: "Plans are nothing; planning is everything." - Dwight D. Eisenhower
pistacchioso 13y ago
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.
- lmm 13y ago
  I don't enjoy pair-programming. I avoid it as much as I can get away with. But looking at the results, it's an inescapable fact that I produce higher-quality code when I do - so for those critical pieces that need to be bug-free, I force myself to do it.
  - berntb 13y ago
    Is that personal experience or a general research result? Is the result better than with careful code reviews [of the critical pieces] (both after writing, but also short checks during development over a code listing and coffee)? Intuitively, everything with coffee involved ought to be better! :-)
    - lmm 13y ago
      Just personal experience. Better than some theoretically perfect practice of careful code reviews? I don't know. Better than code reviews as actually implemented everywhere I've worked? Yes. (In particular I find it's really hard to maintain the discipline of carefully going through each other's code when you know that most of the time you won't find anything)
    - louthy 13y ago
      Coffee is certainly my pair! :)
- JackMorgan 13y ago
  Check out my reply on another comment: https://news.ycombinator.com/item?id=6927170 https://news.ycombinator.com/item?id=6927170. That being said, I do miss solo work, because I could get into the zone, and even if I was going down the wrong path, it was ME doing it, master of my own domain. It feels like I'm alone on my boat sailing into uncharted waters, an adventure. At its best, pairing feels like being part of a tactical response team, at its worst: like there is a machine that turns my brain cycles into money, and they let me keep some of the money at the end. Edit: Rereading both comments, apparently pairing makes me wax with metaphors, like a... nah
inglor 13y ago
Another post saying nothing by uncle Bob. His ability to say nothing never ceases to amaze me -_-. 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.
lifeisstillgood 13y ago
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.
- pjmlp 13y ago
  In the enterprise world I move on, it is mostly a checklist to say a project is agile. Many companies are still run waterfall like, or without any kind of process. When we bring in agile methodologies into the project, it starts slowly, but eventually everything is in place and everyone is doing it in an agile way (XP, SCRUM, whatever). When the first project escalation arrives, or the deadlines are not possible to be achieved, the developers start slowly going back to the original way of working. In the end you get mini-waterfall projects with a sprint duration, but the management puts agile on the project bullet points.
  - lifeisstillgood 13y ago
    I know the feeling - and my view is a bit brutal - but it's down to tools and people. For most enterprises automated build, test, deploy (ie CI/CD) is the one missing tool and one absolutely necessary tool to capture and keep benefits of agile - it's capital. And also for most enterprises you could lose 1/3 of the IT staff without noticing.
    - henrik_w 13y ago
      As edw519 tweeted: (Great Process + Average People) < (Average Process + Great People)
    - pjmlp 13y ago
      Fully agree. In the end what we get from those projects is waterfall with CI, which is still better than how things used to be on the old days. Although, one has this feeling of playing Quixote all the time.
barrkel 13y ago
The things that I remember XP being controversial 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. 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. Test-first TDD is even less popular. Norvig vs Jeffries was enlightening - http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ . 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. 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. 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.
- henrik_w 13y ago
  I don't agree with "making code easy to test tends to over-abstract it". The dependencies are there no matter what, but they become more obvious when you try to test the code in isolation. I think the main benefit of TDD is the way it forces you to break the program apart in smaller, less dependent pieces. The end result is better structure and less dependencies between parts.
  - barrkel 13y ago
    I fundamentally disagree with you. If the goal in writing software is to reduce it to a set of pieces that plug together, I'd agree. But it's an arbitrary metric and not an absolute measure of quality, not by a long shot. Note that I don't say "composable", because composability is something that needs to be designed in, and it isn't usually clear how to do it best until the third or so time around - the rule of threes. Furthermore, I don't say reusable, because reusability is something that also needs to be designed for. In particular, reusability in such a way that software can evolve over time without breaking clients (reusers) of the abstraction demands a tight and constrained contract that is broadened carefully, while testable components demand broad and flexible contracts, otherwise not everything would be available to be tested. Every part that testing has forced you to break out to be individually addressable is a part that you cannot remove in a refactoring that significantly changes the way a library solves its problem. A library that has been broken into parts that are neither composable nor reusable is simply over-complex. Almost every extant Java library is like this! Of course, if you just write end software in small teams, none of this is relevant to you. But it is crucial in library design, especially when client code is outside of your organization.
khaledh 13y ago
http://programming-motherfucker.com/ http://programming-motherfucker.com/
thebear 13y ago
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.
grimer 13y ago
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. 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. I'm sure not everyone feels the same way, but I suspect I'm not alone in that opinion.
- bjourne 13y ago
  I'm exactly the same. And it annoys me greatly that being hypersocial and actually wanting to sit around in noisy environments is considered a prerequisite for many jobs. Not everyone wants to work that way.
- philbo 13y ago
  You looking over someone's shoulder or them looking over yours is definitely not pair programming though. It is exhausting though, I agree with that part.
- dlr720 13y ago
  from my experience it's not everything or nothing. In fact I would say i have never done a XP project where we did everything, but we almost always add tests (what %, simply depends on the project), and they always gave us tremendous insights, we did some level (mostly very little) paring (on either super hard or super critical code) and it always helped get thru the code or provide what mgmt needed, more then one person to understand something that was too critical to leave to only one person. people need to enjoy what they do, and employers need to understand if you want strong talent you need both to work as a team (not shove "do it this way" down people's throats) and XP requires BUY IN. - BTW I am a CTO who has been pushing XP on all dev projects for the past 5 years and I don't code :-)
deleted 13y ago
[deleted]
steven2012 13y ago
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.
asdasf 13y ago
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.
city41 13y ago
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 is 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.
- dack 13y ago
  I'm interested in seeing your blog post - subscribed in anticipation! I definitely agree with the slower bit, but my experience has showed that paired-on code is generally higher quality as the engineers discuss what really should be done and the semantics of what's being built. There are definitely tasks in which I would avoid pairing - specifically those that are either very ill-defined (like a spike or bug hunt) or too easy (write some data transformations). However, the tasks that should result in a clean, well tested API with edge cases taken care of, tend to be higher quality while pairing in my experience.
FrankenPC 13y ago
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.
ColinDabritz 13y ago
The Ten Year Agile Retrospective: http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).a... From June 2011, this article covers four key success factors for the next 10 years of agile. Great thinking on software development.

99 points by joseph_cooney 13y ago

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 despite the methodology (like RUP, or company internal methodologies), but here was a system that actually helped. Truly revolutionary at the time.

ollysb 13y ago
The strange thing is that this is how everyone begins to program you write a little code and get something working. Then you add a little more, reorganise things a little and keep going. It's a natural process that somehow gets trained out of us in CS courses. We're taught how to plan a whole system and them build it. Long running projects interacting with an infathomonable number of users put paid to that though. I think the thing extreme programming got most right is that software is about people. Telling the computer what to do is the easy bit. Figuring out what the users want them to do is the hard part.
- henrik_w 13y ago
  Exactly. You grow software. I really like this quote (by John Gall): "A complex system that works is invariably found to have evolved from a simple system that worked."
- discreteevent 13y ago
  The main thing for me is that its virtually impossible to build a complex system (essentially complex that is) without having good feedback and then adjusting the design to fit. That feedback comes from testing, review and the customer. The shorter the feedback cycle the quicker you settle on the target. The XP book helped spur this on in an age where a lot of people had lost the run of themselves. However these ideas were around and practiced since software development started: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it... And before that for other activities: "Plans are nothing; planning is everything." - Dwight D. Eisenhower

pistacchioso 13y ago

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.

lmm 13y ago
I don't enjoy pair-programming. I avoid it as much as I can get away with. But looking at the results, it's an inescapable fact that I produce higher-quality code when I do - so for those critical pieces that need to be bug-free, I force myself to do it.
- berntb 13y ago
  Is that personal experience or a general research result? Is the result better than with careful code reviews [of the critical pieces] (both after writing, but also short checks during development over a code listing and coffee)? Intuitively, everything with coffee involved ought to be better! :-)
  - lmm 13y ago
    Just personal experience. Better than some theoretically perfect practice of careful code reviews? I don't know. Better than code reviews as actually implemented everywhere I've worked? Yes. (In particular I find it's really hard to maintain the discipline of carefully going through each other's code when you know that most of the time you won't find anything)
  - louthy 13y ago
    Coffee is certainly my pair! :)
JackMorgan 13y ago
Check out my reply on another comment: https://news.ycombinator.com/item?id=6927170 https://news.ycombinator.com/item?id=6927170. That being said, I do miss solo work, because I could get into the zone, and even if I was going down the wrong path, it was ME doing it, master of my own domain. It feels like I'm alone on my boat sailing into uncharted waters, an adventure. At its best, pairing feels like being part of a tactical response team, at its worst: like there is a machine that turns my brain cycles into money, and they let me keep some of the money at the end. Edit: Rereading both comments, apparently pairing makes me wax with metaphors, like a... nah

inglor 13y ago

Another post saying nothing by uncle Bob. His ability to say nothing never ceases to amaze me -_-. 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.

lifeisstillgood 13y ago

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.

pjmlp 13y ago
In the enterprise world I move on, it is mostly a checklist to say a project is agile. Many companies are still run waterfall like, or without any kind of process. When we bring in agile methodologies into the project, it starts slowly, but eventually everything is in place and everyone is doing it in an agile way (XP, SCRUM, whatever). When the first project escalation arrives, or the deadlines are not possible to be achieved, the developers start slowly going back to the original way of working. In the end you get mini-waterfall projects with a sprint duration, but the management puts agile on the project bullet points.
- lifeisstillgood 13y ago
  I know the feeling - and my view is a bit brutal - but it's down to tools and people. For most enterprises automated build, test, deploy (ie CI/CD) is the one missing tool and one absolutely necessary tool to capture and keep benefits of agile - it's capital. And also for most enterprises you could lose 1/3 of the IT staff without noticing.
  - henrik_w 13y ago
    As edw519 tweeted: (Great Process + Average People) < (Average Process + Great People)
  - pjmlp 13y ago
    Fully agree. In the end what we get from those projects is waterfall with CI, which is still better than how things used to be on the old days. Although, one has this feeling of playing Quixote all the time.

barrkel 13y ago

The things that I remember XP being controversial 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. 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. Test-first TDD is even less popular. Norvig vs Jeffries was enlightening - http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ . 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. 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. 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.

henrik_w 13y ago
I don't agree with "making code easy to test tends to over-abstract it". The dependencies are there no matter what, but they become more obvious when you try to test the code in isolation. I think the main benefit of TDD is the way it forces you to break the program apart in smaller, less dependent pieces. The end result is better structure and less dependencies between parts.
- barrkel 13y ago
  I fundamentally disagree with you. If the goal in writing software is to reduce it to a set of pieces that plug together, I'd agree. But it's an arbitrary metric and not an absolute measure of quality, not by a long shot. Note that I don't say "composable", because composability is something that needs to be designed in, and it isn't usually clear how to do it best until the third or so time around - the rule of threes. Furthermore, I don't say reusable, because reusability is something that also needs to be designed for. In particular, reusability in such a way that software can evolve over time without breaking clients (reusers) of the abstraction demands a tight and constrained contract that is broadened carefully, while testable components demand broad and flexible contracts, otherwise not everything would be available to be tested. Every part that testing has forced you to break out to be individually addressable is a part that you cannot remove in a refactoring that significantly changes the way a library solves its problem. A library that has been broken into parts that are neither composable nor reusable is simply over-complex. Almost every extant Java library is like this! Of course, if you just write end software in small teams, none of this is relevant to you. But it is crucial in library design, especially when client code is outside of your organization.

khaledh 13y ago

http://programming-motherfucker.com/ http://programming-motherfucker.com/

thebear 13y ago

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.

grimer 13y ago

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. 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. I'm sure not everyone feels the same way, but I suspect I'm not alone in that opinion.

bjourne 13y ago
I'm exactly the same. And it annoys me greatly that being hypersocial and actually wanting to sit around in noisy environments is considered a prerequisite for many jobs. Not everyone wants to work that way.
philbo 13y ago
You looking over someone's shoulder or them looking over yours is definitely not pair programming though. It is exhausting though, I agree with that part.
dlr720 13y ago
from my experience it's not everything or nothing. In fact I would say i have never done a XP project where we did everything, but we almost always add tests (what %, simply depends on the project), and they always gave us tremendous insights, we did some level (mostly very little) paring (on either super hard or super critical code) and it always helped get thru the code or provide what mgmt needed, more then one person to understand something that was too critical to leave to only one person. people need to enjoy what they do, and employers need to understand if you want strong talent you need both to work as a team (not shove "do it this way" down people's throats) and XP requires BUY IN. - BTW I am a CTO who has been pushing XP on all dev projects for the past 5 years and I don't code :-)

deleted 13y ago

[deleted]

steven2012 13y ago

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.

asdasf 13y ago

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.

city41 13y ago

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 is 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.

dack 13y ago
I'm interested in seeing your blog post - subscribed in anticipation! I definitely agree with the slower bit, but my experience has showed that paired-on code is generally higher quality as the engineers discuss what really should be done and the semantics of what's being built. There are definitely tasks in which I would avoid pairing - specifically those that are either very ill-defined (like a spike or bug hunt) or too easy (write some data transformations). However, the tasks that should result in a clean, well tested API with edge cases taken care of, tend to be higher quality while pairing in my experience.

FrankenPC 13y ago

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.

ColinDabritz 13y ago

The Ten Year Agile Retrospective: http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).a... From June 2011, this article covers four key success factors for the next 10 years of agile. Great thinking on software development.