Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

Beck and Andres on Extreme Programming 321

Posted by ScuttleMonkey from the not-terribly-extreme dept.
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."
This discussion has been archived. No new comments can be posted.

Beck and Andres on Extreme Programming More

Beck and Andres on Extreme Programming

Comments Filter:

  • Extreme... (Score:4, Funny)

    by celardore ( 844933 ) on Tuesday September 19, 2006 @06:23AM (#16136767)
    I was hoping for something a little closer to Extreme Ironing. [extremeironing.com]

    That would have been cool.
  • This is too extreme even for slashdot...

  • Overrated (Score:3, Insightful)

    by seti ( 74097 ) on Tuesday September 19, 2006 @06:34AM (#16136790) Journal
    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: (Score:2)

      by Ed Avis ( 5917 )
      'in your opinion'... how many times have you tried it?

      • Re:Overrated (Score:5, Interesting)

        by Spicerun ( 551375 ) <spicerun@@@gmail...com> on Tuesday September 19, 2006 @07:23AM (#16136945)
        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 (Score:4, Funny)

          by sammy baby ( 14909 ) on Tuesday September 19, 2006 @08:38AM (#16137295) Journal
          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: (Score:3, Insightful)

          by Anml4ixoye ( 264762 )
          Some comments:

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

          No, companies want to pay for what is going to deliver them the biggest ROI for the least amount of money. They don't care how many people are on a job, as long as they get the profit in the end.

          2. As with any other method, it assumes all the specs and implementation have be

    • Re:Overrated (Score:5, Insightful)

      by hclyff ( 925743 ) on Tuesday September 19, 2006 @06:51AM (#16136838)
      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: (Score:2, Insightful)

        by BiggerIsBetter ( 682164 )
        Like any kind of engineering, software engineering needs as much face to face collaboration as possible.

        You really think XP is Engineering?

        • Re:Overrated (Score:5, Insightful)

          by Peter La Casse ( 3992 ) on Tuesday September 19, 2006 @07:29AM (#16136971)
          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.

          • Sorry to ask, but can someone give an example of a field of "real engineering" which uses formal methods to ensure correctness, and of the formal methods used?

            • Sorry to ask, but can someone give an example of a field of "real engineering" which uses formal methods to ensure correctness, and of the formal methods used?

              I would also be interested in what that is, if anyone knows. As far as I know, such "real engineering" means that the design of the bridge is put into the computer, and the computer simulates the forces of gravity, wind, and whatnot, and monitors the simulated stresses on the materials, comparing those against established safe parameters for those

              • I'm not a real engineer, but my layman's understanding is that the engineering equivalent of formal methods involves the mathematical calculation of loads and stresses.

                • Re: (Score:2, Informative)

                  by aaribaud ( 585182 )
                  As a non-layman, highly SW-based, real enough engineer (and other than that an almost normal person), I would not parallel, for instance, structural analysis in civil engineering with formal methods in SW engineering. "Formal method" is the name of a specific kind of SW analysis tool, based on mathematically proving the software, not taking stress scenarios into account (stress simulation for SW is called "testing" :) ).
            • Chip design is a good example of such uses in "real engineering". The whole semiconductor industry is permeated with "strongly formal" tools implementing different types of formal methods at their core. These vary hugely, from loose fuzzy logic design aids to stronger expert system parameter, timing and topology validation, to the full blown formal methods that a language-based computer scientist would recognize.

              And it's been going on for decades. The FPU of the well-known transputer CPUs from the 80's w

            • Re: (Score:3, Informative)

              by GileadGreene ( 539584 )
              Off the top of my head:
              • Structural engineering - static load analysis of simple structures, finite-element modeling of complex structures
              • Digital hardware design - boolean logic, circuit simulation, more recently formal verification via model-checking and higher-order logic
              • Control engineering - frequency methods for stability analysis (PID controllers), linear algebra for the derivation of optimal control laws
              • Spacecraft trajectory design - pretty much all orbit analysis is mathematical in nature, and eve

        • Re: (Score:2)

          by MobyDisk ( 75490 )
          If it isn't engineering then you are doing it wrong.

          I recommend Extreme Programming Refactored [slashdot.org] if you are interested in taking the best parts of extreme programming and mixing them with a traditional waterfall approach to make a nice form of "moderate programming."

      • Re:Overrated (Score:5, Insightful)

        by Angst Badger ( 8636 ) on Tuesday September 19, 2006 @07:20AM (#16136934)
        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.
        • Have you actually tried XP? Because to me, what you write sounds like somebody that hasn't tried it, and just feel that this can't work, and passive-aggressively accuses those that have tried it and found it to work of being passive-aggressive ;)

      • Re: (Score:2)

        by njdj ( 458173 )

        Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.

        That's because most organizations don't know how to run code reviews properly.

        For example, the reviewers should not be in a position of authority. Their role is to raise issues with the code. How to resolve those issues is entirely at the discretion of the programmer. Whether an issue requires any action at all is the programmer's decision.

        Most programmers want to do excellent work, a

      • Re: (Score:2)

        by g2devi ( 898503 )
        > Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer.

        It depends on the personalities. It likely works well if you have a uniform team, but it you have a diverse team (which is a good thing since your weeknesses are compensated by someone else's strengths), it can be very suboptimal. For instance, if you put a reflexive analytical introvert with a shoot from the hip intuitive extrovert, the extrovert will more than likely steamroll over most

        • Re: (Score:3, Insightful)

          by murdocj ( 543661 )
          The parent summarizes very well what I find problematic with pair programming. I'm a slower "let me walk thru it" kind of guy. I also sometimes need to just dummy up some throwaway code to see how something works. Having me pair program with a faster, "just do it this way" guy drives me nuts, because I feel like I'm being reduced to a typist.

          I have had successful "pair programming" sessions at my old job, but that was before I even knew what pair programming was. When someone had a tough nut to crack, w

      • Re: (Score:2)

        by E++99 ( 880734 )

        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.

        Right, come on! Everyone knows that all programmers are extroverts! Programming should be a social event! Besides, the dramatic spike in programmer suicides will only drive up the average salary. If you don't think that the

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

        Notice that he said 'programming peers' -- the coders on the development team sit down, without management, and peer review the code.

        This is why the open source development model works so well -- all the developers are essentially peers working together on the same project.

      • Re: (Score:3, Insightful)

        by 1lus10n ( 586635 )
        Maybe to managers who dont understand the typical coder they should be an endagered species. To me I look around at corporate software and I am wholly unimpressed. I look at the things that the "overnighters" have accomplished vs the things the guys wearing ties and sitting in cubicles have accomplished and I pick the "overnighters" without any hesitation, flow charts, fancy buzz words or any fluff.

        You'll notice that firms who force crap like XP (but not limited to) onto coders fail in the long term. (o

    • Re: (Score:3, Insightful)

      by Aladrin ( 926209 )
      I mostly agree. However, you've forgotten that not all programers ARE like that. Some do actually work well when that close to someone else. I would love to find another programmer of my level (too much higher or lower would cause many problems, I'm sure) and try it. I suspect I'm too hard-headed-control-freak to allow someone else to do things while I just watch, even half the time. But there are people who can and DO do pair-programming and produce code faster, with fewer mistakes.

      Unit testing is my

      • Re: (Score:3, Interesting)

        by Eivind Eklund ( 5161 )
        It actually works good even with a large experience/skill disparity between the programmers. I've only had the experience from the senior perspective - the juniors have said it worked well for them too. As they're still my friends (even though I've quit working with them), I believe them :)

        Eivind.

    • You often see arguments like this... I like this part, I think that part doesn't work well...

      The XP books make very clear that it's either all or nothing. They don't claim that pair programming by itself is always useful, they just claim that this whole set of techniques taken together is useful. If you're going to do all the other things XP says, XP says you should combine it with pair programming.

      If you're not using all the elements (on-site client, pair programming, collective code ownership, etc etc e

      • Re: (Score:3, Interesting)

        by CastrTroy ( 595695 )
        Pair programming may stop people from wasting time on slashdot, however, they seem to waste time in a lot of other ways. Like whether a specific for loop should be written as for(i = 0;imyArray.length();i++) or as for(i = 0;i=myArray.length()-1;i++). That and whether the opening brace should be on same line following the for statement, or on the next line. Oh, and whether certain things should be put in functions, or put inline in the code. Peer programming, while I can see the advantages of having some
        • I've had similiar problems with it. It's also very difficult to get the balance of effort right. If you pair someone who has strong religious beliefs about the "right" way to do things with another who is more flexible, it ends up being more efficient to let the religious one "drive".
        • Like whether a specific for loop should be written as for(i = 0;imyArray.length();i++) or as for(i = 0;i=myArray.length()-1;i++).

          I don't know what language you are using, but it almost certainly shouldn't be written that way unless you are performing an operation in the loop that changes the number of elements in the array. Unless your language allows you to specify that the length() function is a pure function (and all other array methods you use are, then you will be testing the length of the array ev

          • You just proved my point. Really in the end, it doesn't make that much of a difference whether you use for each, ilength, or i = length -1. I mean, you could argue that it's more efficient to use a for each, but do you really know what's going on under the hood, and whether or not it's just checking the length function anyway. How do you know you're at the end of the array unless you check the length? I guess you could be checking a variable instead of calling a function, but unless you're going for the u
            • I mean, you could argue that it's more efficient to use a for each, but do you really know what's going on under the hood, and whether or not it's just checking the length function anyway.

              In the case of Objective-C, which is the language I use the most, yes I do. I wrote the FOREACH macro that I use, and it does things like caching instance method pointers for efficiency. Since it's a macro, I know I am safe from copy-and-paste errors, which I would not be if I just used an idiom as you suggest.

              For t

        • Re: (Score:2)

          by raduf ( 307723 )

              It's a matter of relationship. Last time (a long ago) when i did pair programming it was lots of fun and very useful. The one writing code took care of the micromanagement and had in mind at most the function he was working on, and the other was two steps ahead. If the side man keeps checking syntax and formating then the whole thing is useless.

      • Good marketing (Score:3, Insightful)

        by ClosedSource ( 238333 ) *
        "The XP books make very clear that it's either all or nothing. They don't claim that pair programming by itself is always useful, they just claim that this whole set of techniques taken together is useful. If you're going to do all the other things XP says, XP says you should combine it with pair programming."

        This is just good marketing. By making this "all or nothing" claim, XP has a built-in excuse that you are invoking here. Ever noticed that you hear the phrase "because you're not doing it right" more

      • Re: (Score:3, Insightful)

        by blowdart ( 31458 )
        But all or nothing is not just an XP problem. All methodologies say their way is best, if you deviate you are a heretic and if it all fails then it's your problem for not following the rules. The people that "invent" a methodology make their money from teaching people how to do it, why would they kill their cash cow by telling people they should just take the bits that work for them? Methodology advocates, like preachers cannot afford to have people think for themselves.
        • A lot of business management books work that way.

          1. Take something obvious or counterintuitive (Doesn't matter if it will really work or not)
          2. Label it with impressive sounding phrases
          3. Copyright a bunch of specific steps (methodology) to do the obvious
          4. Write and publish a 400 page book about the methodology steps using your new phrases
          5. Sell it to PHBs and incompetents
          6. Profit!
          7. When complaints about non-success arrive, arrange seminars at hundreds of dollars per seat.
          8. Give Seminar
          9. More

        • Re: (Score:3, Informative)

          by e2d2 ( 115622 )
          Actually what you are saying is completely not true when it comes to XP. They clearly say in their docs that you can choose the pieces of the methodology that you feel valuable and leave out ones you don't use.

          It also was extracted from a real world project methodology used by the C3 project. So in fact this methodology came from real world practices, not out of someone's ass as you imply:

          http://www.xprogramming.com/Practices/xpractices.h tm [xprogramming.com]

          I've been in environments where we've used XP, I've been in environ
    • Programmers are solo beasts

      Really? So what percentage of major, important or commonly used programs were written by only one person?

    • Re: (Score:3, Interesting)

      by Peter La Casse ( 3992 )

      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.

      Test driven development is seductive; who wouldn't want to have all those automated tests in order to check changes to their code? However, I find it hard to put into practice

      • It seems to me that test driven development is a great way to generate throw-away code. Writing solid unit tests after you have written the code, provides the same benefits as writing it before except you don't have to write as many incremental tests.

      • Re: (Score:2, Interesting)

        by Stooshie ( 993666 )

        ... and changing even a small piece of code often requires changing a lot of tests. If you can offer any suggestions about how to improve that, I'm all ears.

        That's the wrong way round. Shouldn't you be rewriting the tests to conform to the new specifications then changing the code for the re-written tests that fail? Doing it your way will make it very difficult to trace code.

        Another way of pair programming could be to have one person writing the tests and one writing the code.

    • Re:Overrated (Score:5, Interesting)

      by MobyDisk ( 75490 ) on Tuesday September 19, 2006 @07:53AM (#16137071) Homepage
      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.

    • Some programmers are solo beasts. Some are not. And it really depend on who they are collaborating with, and the setting around it.

      Have you noticed the "with snacks" meme that is going around everywhere in XP? "We don't know why, but this works much better when there are snack available in reach of the programmers." This one is true, in my experience. Pair programming work much better with it in place...

      Eivind.

    • Re: (Score:3, Insightful)

      by vhogemann ( 797994 )
      I enjoy pair programming, really.

      Quite often it prevents me from doing very stupid errors. Having another person looking at what you're doing, and making questions about that pice of code, and suggestions makes you pay more attention, and gives a precious feedback.

      Also, when I'm co-piloting (not at the keyboard, that is) I feel this incredible urge to return to my desktop and code something. Watching other people code, and talking about his code makes me want to code, its weird, but I always feel more motiv

    • Re: (Score:2)

      by LauraW ( 662560 )
      Some of the ideas, such as test-driven development (although this concept is not restricted to XP), work well.

      I agree. TDD takes a bit of time to get used to, but once you're doing it regularly it comes more naturally. Once you have the tests, it can really change your development style. Yesterday I started a fairly huge refactoring of part of our system, and I'd shudder to think what it would be like to do this "without a net" if we didn't have the test coverage.

      Another aspect of XP that I like is t

  • Laundry? (Score:4, Funny)

    by LaughingCoder ( 914424 ) on Tuesday September 19, 2006 @06:58AM (#16136860)
    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"? (Score:5, Funny)

    by 10Ghz ( 453478 ) on Tuesday September 19, 2006 @07:01AM (#16136870)
    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"? (Score:5, Funny)

      by Anonymous Codger ( 96717 ) on Tuesday September 19, 2006 @07:41AM (#16137011)
      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.
      • And in other news, you are commenting on things you haven't tried in the real world, right?

        Because I can't believe anybody can conclude, after having tried XP, that it is completely useless in the real world in all cases. There are cases where it is a good fit - many cases - and there are some where it is a bad fit, but after having taken the risk of actually testing it, it's clear that it is tremendously useful in the right context.

    • The name comes from introducing some good practices and then doing them extremely ("Turning them up to 11", in the words of Kent Beck).
      • "Don't let your programmers be tired" -> "Forbid programmers from working overtime".
      • "Do code review" -> "Do code review in real time, by pair programming"
      • "Test" -> "Test everything, immedately, by not writing code until you have a failing test"
      • "Get customer feedback" -> "Release in very short cycles, and have a customer owner that decide how things should wor

      • Re: (Score:2, Funny)

        by Anonymous Coward
        You have some misspellings there... let me correct you:
        • "Don't let your programmers be tired" -> "Forbid programmers from working overtime at your own peril as you should realize that a programmer is a real, live adult human being which happens to be a professional and therefore can take care of his own work hours due to the fact that he has been living with himself for quite a few years and knows perfectly well when he's tired and when he's not, and resents being treated like a child by a moronic idiot w

  • One of the best quotes ever... (Score:4, Insightful)

    by chuckplayer ( 994706 ) on Tuesday September 19, 2006 @07:09AM (#16136898)
    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 ? (Score:4, Insightful)

      by aepervius ( 535155 ) on Tuesday September 19, 2006 @08:09AM (#16137148)
      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 ? (Score:4, Interesting)

        by Cederic ( 9623 ) on Tuesday September 19, 2006 @10:53AM (#16138218) Journal

        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.
    • Since Ken Beck isn't really a programmer it isn't surprising.

    • Re: (Score:2)

      by jeti ( 105266 )
      Does this imply that managers like to be yelled at and aren't interested in new toys?
  • 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...

  • Real Extreme Programming (Score:5, Funny)

    by niceone ( 992278 ) on Tuesday September 19, 2006 @07:28AM (#16136962) Journal

    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

    • Re: (Score:2)

      by raduf ( 307723 )
      3. Getting your interface specs from a dieing man after being helicoptered across town

      Omg! This one is scary!
  • 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.
  • 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: (Score:2)

      by s31523 ( 926314 )
      Yes, one of the ideas is to drive the development of a product through tests that are written first. The one concept missing is that this can't be the only testing since theses tests are mostly low-level, i.e. at the module/class level.

      Here is a real example. I work in aerospace, and my responsible area is navigation. We use INS's as the base latitude/longitude for position estimation. We have 3 of them, for redundancy purposes. We have a heirarchy of rules which decide which INS will drive the navig
    • In my experience the goalposts move as you write the code... 'oh, that's possible? then can you also do this, and it would be nice if a widget popped up here, and...'

      Writing the tests first means you're going to be forever updating them as the specs change.

      • Re: (Score:2)

        by Aladrin ( 926209 )
        As opposed to writing them just after you code something, and the specs change anyhow? What's it matter if you code the test before or after the actual code, if the specs change -after- you've done both?

        One big idea from test-first is to keep you coding things that actually matter, instead of adding stuff 'I'll need later' and then never do. There's also the obvious benefit of having tests to cover everything.
        • Horseshit. Writing to pass the test which was written first is absolute horseshit. First, writing JUST a test script is utter nonsense. The only true way to test these things is to have a USER test it. So frigging what if the test passes....if the user doesn't like the arrangement of the controls or the color of them then you have to change it....yeah, it's crap, but trust me...I would rather NOT have 400 different colors (if you let them change this on their own) to look at when I go to try to fix some
  • It looks like it's had the curse of consultants beat it down with their theory and "improvements"
  • 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.
  • 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

  • Treat programmers like other professionals! (Score:3, Insightful)

    by Rearden82 ( 923468 ) on Tuesday September 19, 2006 @08:10AM (#16137151)
    "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?
    • That was the most sensible post I've seen here so far.

    • Re:Treat programmers like other professionals! (Score:4, Insightful)

      by sh4na ( 107124 ) <shana...ufie@@@gmail...com> on Tuesday September 19, 2006 @08:46AM (#16137336) Homepage
      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.

    • Re: (Score:2)

      by bytesex ( 112972 )
      This is insightful shit. Personally, although I've never tried or been forced into XP, I think it's typically something for young people; you know, the psychological approach. Young geeks work a lot (good), make many mistakes (bad), and don't communicate very well with other people other than their peers, and communication is what XP is all about. This frustrates managers, so they make sure, through XP, that they can still work a lot, but make fewer mistakes (through pairing, and testing a lot), and comm
  • There is also one good tool called Petra supporting extreme programming prototyping http://petra.cleverlance.com/ [cleverlance.com] We use it and love it.

    • Re: (Score:3, Insightful)

      by ynohoo ( 234463 )
      What's up, didn't you like the "Funny" mod you got the last time you posted this?

      I must admit I found this site disconcerting - I'm unlikely to buy design tools from people who look (on this site) like they are in the "manic" phase of their bi-polar disorder...

  • Agile Programming == Late night infomercial (Score:3, Insightful)

    by MrData ( 130916 ) on Tuesday September 19, 2006 @09:17AM (#16137533)
    Agile Programming is like a late night infomercial without the "these results are not typical" disclaimer.

  • Extreme Hogwash (Score:5, Insightful)

    by roman_mir ( 125474 ) on Tuesday September 19, 2006 @10:05AM (#16137827) Homepage Journal
    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.

  • Mostly, XP improves Kent Beck's net worth ... (Score:3, Insightful)

    by joe_n_bloe ( 244407 ) on Tuesday September 19, 2006 @11:18AM (#16138422) Homepage
    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.

Slashdot Top Deals

My sister opened a computer store in Hawaii. She sells C shells down by the seashore.

Close