13 thoughts on “Extreme Programming”

  1. Lots of XP probably isn't relevant to most statistics, IMO, because it's targeted at medium-size teams of programmers (5-10 people) who are typically implementing business logic or some other well-understood process.

    However, the practices of rigorous test-driven development and peer review and continuous integration (e.g. Sweave or Inference for R) and iterative development are useful for practically all intellectual activities; Kent Beck certainly didn't invent them. And, as they say, the fundamental principle of XP is to observe and measure your productivity, altering your process to do what works.

  2. In programming,it's a very old idea, of course. That style works well on small projects, and can work on larger projects where thete's not a lot of interdependency.

    John's strategy of debugging by deleting code is a good heuristic within almost any paradigm. I apply it to almost all my writing, actually – if a sentence reads awkwardly, I try cutting it. If the paragraph still makes sense, I probably didn't need it that much.

    Apart from a few specific instances I am not sure how XP would apply in statistics, apart from the "simplest thing that works" heuristic – there's a lot to be said for that; Tukey tried that, actually, not just in the simple EDA stuff, but he also had his various Quick tests and a few other "so simple you can do it in your head" ideas.

  3. As someone who had to manage a software team of 20+ developers, I have seen gains in productivity, reduction in defect rates and anecdotal improvement in morale probably due to the collaborative nature of the process. However, it is a huge culture shock to those who are used to the 'waterfall' model (requirements, design, code, test…). Unfortunately, I have not seen any real studies on the subject, and I am not sure under what circumstance it is usefull or if I was just lucky to observe positive results.

  4. In some circles that's a bit of a loaded question. However, I've always liked this view:

    So the consultants, now having lost their primary customer, were at a bar one day, and one of them (named L. Ron Hubbard) said: "This nickel-a-line-of-code gig is lame. You know where the real money is at? You start your own religion." And that's how both Extreme Programming and Scientology were born.

  6. Depends really on whether or not you know where you are going and what you are doing. It's really just A*-search-style project management, and you have to have a decent design heuristic to be good at it. So good to expert, XP is good, but it's probably not a good learning device.

  7. Programmers' work rules aren't same as stats consultants or academia. Most "trad" software management materials centered on a work environment where most participants weren't far out of school, and skills were shakier.

    Extreme programming lit is a corrective for a more experienced segment of programmers, with a programming equivalent of "math maturity". And it's also for their mgmt.

    There's no Tantric path to maturity for newbies, and the cherry-picking nature of a workplace means some will be loaded to bear with matures, and some will be bereft of them.

    And some projects may want more assurances than others. "He or she gets it" might not work.

    The programming management field is filled with mines generally. Which isn't surprising when a few studies suggest productivity differences of 10 to 1 between employed programmers.

  8. I take XP as advice from experienced software people and nothing more. Like any advice, it becomes more clear over time as you evaluate your own mistakes in hindsight.

    One idea that I use in research as well as software is iterative development. This is a middle ground between planning your all your tasks in advance and planning no tasks in advance. You divide the project into small bits and work on those bits to produce frequent results. Once you've got some bits done, you go back and look at the rest of your plan and evaluate how realistic it is and where you want to go next. With software, the bits are usually features.

    I find this approach useful on research projects, as always mixed with a liberal amount of personal judgment and experience. Research varies widely and projects can get bogged down in various ways. So I break my work into tasks that will take a few days and produce a concrete result (even if it's nearly inconsequential in the larger picture). Those small tasks get bunched into goals of a few weeks in length.

    The mental exercise helps me keep on track and keep moving. It gives me little goals that are constantly being met, and also forces me to evaluate where I'm going with the whole thing and when I'll have some results.

  9. I think pair programming adapted to statistics (pair data analysis?) would be pretty interesting. Could be interesting to support explicitly in a stat consulting course.

  10. I was reading about extreme programming on wikipedia. The story of how it came about is interesting — during the development of a payroll system for Chrysler using a computer language called Smalltalk.

    There was another methodology called Unified Modeling Language that grew out of the military's efforts to contain uncertainty in scheduling of software projects that involve large numbers of programmers.

    I'd love to see a sociological analysis of these things. I've looked high and low, and haven't found anything. I've often heard that XP is meant for "experienced" programmers, but I've never really understood what an experienced programmer is, and what a recent graduate would need to know in order for XP to be useful to them.

  12. XP's rule of pair programming works well in a lot of different situations. The person on the keyboard, steer or steering wheel has his perception greatly limited (called tunnel vision) because of the manual task. A second person (e.g. a car race pilot) can then handle the larger picture and can concentrate on the wider perspective.

Comments are closed.