EXtreme Programming.. ..controversy



  • I'm on a computer science course and soon enough I'll be taking part in a presentation concerned with extreme programming. My bit will be to deal with the controversies surrounding XP. I specifically asked to be presenting this bit as it has more potential to be at least humorous than the other aspects of the development method.

    I have done all the googles etc but it's still as dry as rye bread.

     Has anyone got any personal issues with XP or entertaining [XP] incidents to share that would be relevant...? At the least any helpful suggestions...?

     

    Many thanks...

     



     



  • Here is a pretty entertaining piece on Google, XP, Agile, etc.

     
    http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html 

    I found this through digg, or Slashdot, or maybe even here - I can't remember. 



  • We've had some discussions about agile methods and XP here, check out those threads:

     
     More on Extreme Programming

     Agile methods work vs don't work

     agile != cowboy

     Does Agile work for standard software development

     

     



  • Well, my advance practical at uni was the development of a software. We could choose what group we would like to join. Basically there were two types: XP and the classical approach. As I had heard the term XP before but had no real clue what was to it I chose the first.

    First I thought XP was another word for a new extreme sport involving monkeys on type writers producing code. :) But soon I learned that it is a very sophisticated and unique approach. At the beginning it was a bit annonying as we were to strictily follow the XP paradigms of which some require a lot of disciplin.

    Well, as you might have googled it up XP includes pair programming, test driven development, refactoring, acceptance tests, cusomter on site, etc...

    As for the pair programming I thought it was interesting so far as that you keep reasigning pairs. Thus everyone gets his/her share of the different aspects of the software and the technologies involved. So basically everyone knows the software and knows how its parts work together. Thus it wont hurt that much if someone leaves the team as that person won't be the only one knowing his/her specific code etc... I guess you can google/wikipedia the other aspects of pair programming if you want.

    There is one real annoying part about XP (unless, of course, your "pair" consists of you and an even more annoying person laughing about every flat joke you make producing sounds like a pig on crack. Er... nevermind that). Anyway, the annoying part is that the test driven approach requires a lot of disciplin as you write unit tests as well as your acceptance tests for basically everything. As one wants to write code instead of tests thats the part thats most likely to be skipped. Fortunately the instructor was really strict on that as well. In the end we had 1600 test cases in out acceptance tests and it did pay off. The tests help you ensure the quality of the software and make it a lot easier to avoid making mistakes. Once in a while you modify a harmless looking line in your code thinking it is alright. Then you run the tests and see that for example 35 tests go wrong. Without a sufficient test coverage you wouldn't have been aware of the bug you produced. It is true that you spend a lot of time writing tests but save more time on the long term than looking for bugs etc...

     
    Another point is refactoring and readability of code and avoidance of commentaries. That is the part that I was the most fascinated about and I still use these guidelines all the time as they are not only applicable to XP.

    Let's talk about commentaries first. If you are a person that is capable of self-critizism and look at your own comments you will most likely find that it fits one of the following categories:

    a)
    ...
    // returns the sum
    return s;
    ...

    for obvious reasons that is quite a redundant comment as we know what the method is supposed to return. :) So remove it.

    b)

    Let's assume we have a method/procedure called "generateLandscape(...)" 

    //  generates the landscape...
    public static void generateLandscape(...) {
    ...

    The method name is self-explanatory and thus does not need such a comment. If you think you need the comment though because the method-name wasn't self explanatory then make the commentary redundant by refactoring. For example, lets assume the name of the method was somehting cryptic like "genLS(...)" then just rename it to "generateLandscape(...)". There is not need to keep your variable names nor you method names short! As you prolly use an editor with autocompletion the length does not matter.

    c) Lets assume you implemented the method "generateLandscape" and find that it has a lot of lines of code. Even if you use selfexplanatory names and structure the code well you may find that the code is hard to understand. Let's assume that the method would first generate some fractal landscape then add water to it and then seed some trees. In that case all you need to do is to identify these parts and extract the respective code in seperate methods. So before refactoring/extracting methods your code would look like this:

    public static void generateLandscape(...) {
    // generate fractal landscape
    ... lots of code...
    // generate lakes/rivers
    .. even more code...
    // plant trees
    ... and more code ...
    }

    Now after extracting the methods the method only has three lines:

    public static void generateLandscape(...) {
        generateFractalLandscape(...);
        generateLakesAndRivers(...);
        plantTrees(...);
    }

    And you have three possibly private methods that are each about third of the size of the original code. Thus the readability of these methods has been increased as you can look at the respective parts of the code independantly from the other methods.

    Ok, I know it sounds pretty obvious but to be honest I never gave this much thought before. It is simple but nifty. There is hardly a need for comments ("If you write comments you did something wrong")! But refactoring is not only useful for increasing modularity and readability of your code, of course, it is also used to restructure your code which is necessary as (a) specifications may change or be added and (b) you keep extending your software as this is an agile approach. So you want to get rid of redundant code and restructure your code so that you can reuse it where it is needed by several independant methods.

    As shown above readability of the code is extremly important and it should be maintained all the time (no slacking when it comes to writing code as well as tests!). Without self-reminding one of that you will end up with a huge pile of WTF code. As opposed to the classical approach there is no long term planning for the structure of the software, thus, constant modification and extension of your software in XP makes this an very important technique in order to keep it clean.

    Another aspect is that XP ensures that you constantly have a software that works (only including the implemented features of course) while in a more classical approach you put together the pieces in the end.

    Discipline is also required when planning and implementing the iterations. You prioritize the tasks. Usually tasks that are easily and quickly implemented usually get a higher priority. So you basically weigh the importance of a task and the quick realisation of tasks against each other. You may be tempted to implement more than is required. That is quite natural as you may think in advance and thus want to write your code for the future tasks ahead. In XP that is generally to be avoided (Write for the present). Firstly specifications may change or the general structure may change rendering your effort void, secondly you dissipate your energy and time on something that is not the task. You end up coding more and more as if it was a bottomless barrel.

    It seems I wrote more than I intended. I do claim my post to be neither complete nor well structured. I merely wanted to point out a few practical things that came to my mind that I thought to be worth mentioning as opposed to formal descriptions that you can look up anywhere. The problem IMHO is that it is hard to talk about certain methods or approaches of software engineering when one never experienced them. Thus I hope I could give my limited and subjective insight to that topic. There is plenty more tell but I simply cannot be bothered. :)

    Generally speaking I believe that XP is a good approach to ensure a high standart of software quality. Nevertheless it is an approach that I think works well with a rather small number of developers which again have to share the right mindframe when it comes to be thorough, honest and have the courage to let go of their (tedious developed) code for the sake of better revised code. It is very team orientated and there is no space for gung-ho developers that want to seize the work to themselves (The code belongs to everyone!). Thus, concerning controversies surrounding XP I would guess that the disadvantage lies in the fact that you need the right people who understand the concepts involved. I guess it can also be argued that you may need to "hold back" concerning certain aspects. Then again I believe that it really depends on several factors which approach to chose. Neither classical nor any agile methods are the philosopher's stone. They are merely a set of different paradigms that work well together.

    Eventhough I do not claim to be an expert on XP, I will be more than happy to answer you any further questions as far as I can.
     

     



     



  • Damn, I can't edit my post...

    Anyway, the issue I may have with XP (apart of annoying team members while programming in pairs) is that it is very hard to come up with the self discipline to follow the guidelines (especially concerning writting all those tests). Thus, I assume it is questionable whether it is realistic to impose this onto the developers. While I may have some stories about XP development none of them really discredits XP. Issues usually arise when you strive from the path and not follow the guidelines. After the practical me and someone else continued the project and from then on it became kinda messy as we didn't really maintain the tests anymore. In the end we ended up with a bunch of workarounds as we were too lazy to restructure the design which degenerated into a random bunch of classes and methods with names that qualified as short stories. As we couldn't rely on our tests anymore we had to manually look for bugs. And it was more than likely that there are still a lot of bugs that haven't surfaced yet. But that's our own fault as we just picked the convenient parts of XP. Well, in the end it only matters if you use this tool right or not. After all, you don't eat soup with chop sticks.



  • [quote user="Phalphalak"]After all, you don't eat soup with chop sticks.[/quote]

     

    Mmm... Soup on a stick.

     

    Anyway, I disagree about "If you need a comment, you've made a mistake."... While it is often the case, sometimes you have an algorithm or workflow that (for whatever reason) is highly complicated/obtuse/unobvious.  Sometimes it can be simplified, but if performance is a factor, sometimes you have to use the complex versions. Commenting in that case is a good thing.

     Also, there are different levels of engineers.  An intern would probably benefit from reading some "somewhat obvious" comments.  I know I've learned a bit about multi-threading considerations just by reading parts of the J2SE API source code.  The comments point out things that are "obvious" to engineers used to multi-threading paradigms, but not to the average Joe Engineer.

    AND! Thing about Poor Paula Bean.  She couldn't be Brillant without someone elses comments  to go by :-)

    Something I think you missed about XP is the willingness to THROW OUT OLD CODE.  If it no longer meets requirements, don't spend more time adapting it when you could write an exact match in the same/less time.

    Code reuse is good, but oft abused.
    Bad Management/Engineering: "Square peg, round hole?  Sand it down!"
    Good Management/Engineering: "Square peg, round hole? Try with the old lathe, but make a rounder peg."
    Great Management/Engineering: "Square peg, round hole? Make a round peg."



  • [quote user="danielpitts"]

    Anyway, I disagree about "If you need a comment, you've made a mistake."... While it is often the case, sometimes you have an algorithm or workflow that (for whatever reason) is highly complicated/obtuse/unobvious.  Sometimes it can be simplified, but if performance is a factor, sometimes you have to use the complex versions. Commenting in that case is a good thing.

    [/quote] 

    Well, it was a rather polarized statement to implicate something went wrong if you see need for comments. Nevertheless there is rarely a need for comments. If it is about commenting on the design or its pattern or explaining let's say the mathematical basis your code may rely on I guess it is ok. Also performance as you said is an issue that may lead to less beautiful code.

    [quote user="danielpitts"]

    AND! Thing about Poor Paula Bean.  She couldn't be Brillant without someone elses comments  to go by :-)

    [/quote]

    I'm rather new to this site. And I never understood what people talked about when refering to the bean thingy. So, Paula = bean bag girl?

    [quote user="danielpitts"]

    Something I think you missed about XP is the willingness to THROW OUT OLD CODE.  If it no longer meets requirements, don't spend more time adapting it when you could write an exact match in the same/less time.

    [/quote]

    Maybe I could have put it more explicitly, but thats what I ment by: 

    the courage to let go of their (tedious developed) code for the sake of better revised code




  • [quote user="Phalphalak"]

    [quote user="danielpitts"]

    AND! Thing about Poor Paula Bean.  She couldn't be Brillant without someone elses comments  to go by :-)

    [/quote]

    I'm rather new to this site. And I never understood what people talked about when refering to the bean thingy. So, Paula = bean bag girl?

    [/quote]

    Here is the link to the appropriate posts.

    The Brilliant Paula Bean 

    The Brilliant Paula Strikes Back
     



  • [quote user="lpope187"][quote user="Phalphalak"]

    I'm rather new to this site. And I never understood what people talked about when refering to the bean thingy. So, Paula = bean bag girl?

    [/quote]

    Here is the link to the appropriate posts.

    The Brilliant Paula Bean 

    The Brilliant Paula Strikes Back

    [/quote]

    We really should make an FAQ... 



  • Beanbag girl is a girl from an ad, look at this thread:
     

    http://thedailywtf.com/forums/thread/87772.aspx



  • I once had a few days of Xtreme Designing. The external art-director would sit next to me and I'd photoshop stuff and we'd make the design together.

    These were the results:

    - a mediocre website design
    - sapped of my strength
    - I never want to see the man again.



  • The biggest problem with the whole Agile/XP vs Waterfall/Predictive controversy is that most (not all) treat their preferred methodology like a religion.  It just like all the discussions about which programming language is the best - the discussions typically degrade to flamewars like the recent ColdFusion debacle.

    What people really need to understand is that each methodology, tool, language, OS, whatever has strengths and weaknesses and none are inherently superior to any other.  It's all about context - some projects are more suited to adaptive methodologies while others are more suited to predictive methologies.  I've used both adaptive and predictive methodologies successfully.  The trick is to determine which one is the best approach for a specific project.

    Long story short, anyone who states that Agile/XP is better than Waterfall/Predictive under all cases (or vice versa) is full of it.  There is no silver bullet - choose the best tool for the task at hand.



  • [quote user="dhromed"]

    I once had a few days of Xtreme Designing. The external art-director would sit next to me and I'd photoshop stuff and we'd make the design together.

    These were the results:

    - a mediocre website design
    - sapped of my strength
    - I never want to see the man again.

    [/quote]

    This is not what I would call XP.
     



  • It was very extreme.



  • [quote user="dhromed"]

    I once had a few days of Xtreme Designing. The external art-director would sit next to me and I'd photoshop stuff and we'd make the design together.

    These were the results:

    - a mediocre website design
    - sapped of my strength
    - I never want to see the man again.

    [/quote]

    That reminds me of something. Once in our computerlab I overheard some students discussing their approach to implementing some game which was probably part of a practical. They were students of our new hybrid study course "medieninformatik" (basically some sort of mix between computer science and some kind of media/design related studies). Whenever seeing these students i cant help myself than to think that this course of studies aims to teach you how to draw a circle in photoshop, a pyramid in 3dstudio max, and write a hello world program without tossing too many exceptions around. Anyway, as I eavesdropped into their conversation I learned that they intended to you use XP as their approach to the project. After they had agreed on that they started to assign their roles in what they perceived to be common XP manner: "Ok, I will surf the web for images that we can use. You wanted to look for sound files, didn't you? And you start creating the login screen... you said you know how to program in flash, aye?" ... I rolled my eyes so extremely that they did a U-turn.
     



  • I tend to agree with &lquot;if you think you need a comment, you need to change the code', although like everything there are of course exceptions. In particular you'd want a comment for

    // Aaronson's algorithm
    // See www.mathworld.com/aaronson
    (code to perform complicated algorithm)

    ... and for ...

    // Workaround for OS/API bug
    (some nasty hack)

    ... and for many iterative/parallel algorithms, where the way you have to write the code (loops and such) interferes with reading what the algo actually does, you'd want a comment to say what it does in an easy to read way.

    Besides, code files look much nicer with some green space ;).



  • To generalise, IMO, good code shouldn't need a comment for *what* it does. However, *all* code needs comments for *why* it's doing it.

    Like anything, there are exceptions, but as a general rule, I find that works best. 



  • If you write comments you did something wrong

     

    That is quite possibly the most incorrect thing I've read all day.  imagine this clip of perl code

    foreach $line (@lines) {

         if ($line =~ /(\d+)\s+(.{12})\s{2}([0-9A-Fa-f{4})) {

            print("Device $3 is set on $2 mode with $1 capacity");

       }

    }

     

    Yeah, you can figure out kind of what form of line it's looking for, but a commend that shows an example of two would surely make it better.

     



  • Presentation over and done. Thank god.

     

    Tutor thought it concentrated too much on the negative aspects which means I've done my bit properly seeing as it stuck. The guys dealing with the positive aspects and advantages of XP merely failed to get their point across.

     
    The fact I spend a lot of time reading the forum links and various other sites on XP helped a great deal. Familiarity with the subject allows you to improvise a lot.
     

    R.Flowers. A very entertaining piece but rather long. No time wasted on reading it tho. At least it raised a laugh, or two.

    "well if ONE programmer sitting at a terminal is good, then TEN must be better, because MORE is ALWAYS better! But most terminals can only comfortably fit TWO programmers, so we'll call it PAIR programming!"

    I did use that bit but it didn't impress..

     Phalphalak , thanks for your extensive posts. I did use the genLand example. Practical examples keep the whole thing a little more interesting IMHO.

    I have never used XP myself but would imagine it to be horrendous to be working with constantly changing specs...  ...and someone watching me code.
     



  • [quote user="tster"]

    If you write comments you did something wrong

     

    That is quite possibly the most incorrect thing I've read all day.  imagine this clip of perl code

    foreach $line (@lines) {

         if ($line =~ /(\d+)\s+(.{12})\s{2}([0-9A-Fa-f{4})) {

            print("Device $3 is set on $2 mode with $1 capacity");

       }

    }

     

    Yeah, you can figure out kind of what form of line it's looking for, but a commend that shows an example of two would surely make it better.

    [/quote]

    I think that is a good example why you should use self-explanatory method names. The code snippet does not include the method declaration. If the methods name would state what it does, this code won't need a comment.  If you want to use the regexp more often you may even want to consider declaring a string variable for it with a self-explanatory name as well.

     

    [quote user="JCDenton"]

    I have never used XP myself but would imagine it to be horrendous to be working with constantly changing specs...  ...and someone watching me code.  Or you might as well declare the regexp in a string variable with an appropriate name in case you may want to use it more often.

    [/quote]

    Well, it's not that specs have to have change all the time just because you are doing XP. One may draw an analogy to an epsiode of MASH where  Maj. Frank Burns learned that MASH stands for "Mobile Army Surgical Hospital" and thus decided the camp had too move a few yards. So I think an advantage of XP is merely that it is easier to cope with changed specs if they change.

    As for the pair programming it always depeneds how you get along. The other person watching is not really supposed to be a watch dog in the sense to judge you. It is just that two pairs of eyes see more and than one. If you are programming and have to explain what you are doing you are much more aware of what mistakes you are about to do. And if you are the person watching you have plenty of time to read your newspaper, eat your sandwich or just have good sleep :)




  • ..darn, cant edit my post again...

    anyway, I just noticed that I accidentally pasted a sentence into JCDentons quote that I ment to put somewhere else.  It's the "Or you might as well declare the regexp in a string variable with an appropriate name in case you may want to use it more often." - part. Sorry!



  • Here's Verity Stob on the subject: 





  • Thanks all.

    This thread is a perfect example of how helpful and friendly this community is. (Taking into account I haven't read the coding questions forum)

     However, there does also seem to be a hell of a lot of flaming , counter flaming , personal attacks and insulting going on in some threads. You'd think there would be a lot of camaraderie in a community of s/w devs who all pride themselves on the quality of their code and who like to distance themselves from the script kiddies and incompetent. I haven't been a member for terribly long but I have read the forums long enough to notice this unattractive characteristic of the community.

     
    The links to other posts presented in this thread are perfect examples on cordial technical discussions which are conducted with decorum and respects towards each other.
     



  • quote user="JCDenton"

     However, there does also seem to be a hell of a lot of flaming , counter flaming , personal attacks and insulting going on in some threads. You'd think there would be a lot of camaraderie in a community of s/w devs who all pride themselves on the quality of their code and who like to distance themselves from the script kiddies and incompetent. I haven't been a member for terribly long but I have read the forums long enough to notice this unattractive characteristic of the community. 

    [/quote]

    IMO, flaming and contraflaming are actually very usefull They help us to separate the things we are really sure of from the things that we do because they have worked in the past. If I cannot explain the advantages of PL/SQL over, say, Java and C#, it probably means that my only reason to use PL/SQL is that I know it well, while I feel wonky in other languages.
     



  • [quote user="ammoQ"]quote user="JCDenton"

     However, there does also seem to be a hell of a lot of flaming , counter flaming , personal attacks and insulting going on in some threads. You'd think there would be a lot of camaraderie in a community of s/w devs who all pride themselves on the quality of their code and who like to distance themselves from the script kiddies and incompetent. I haven't been a member for terribly long but I have read the forums long enough to notice this unattractive characteristic of the community. 

    [/quote]

    IMO, flaming and contraflaming are actually very usefull They help us to separate the things we are really sure of from the things that we do because they have worked in the past. If I cannot explain the advantages of PL/SQL over, say, Java and C#, it probably means that my only reason to use PL/SQL is that I know it well, while I feel wonky in other languages.
     

    [/quote]

    <flame>Hm, I think you are talking about arguing or discussing a topic but not flamming.  While a discussion may be led in a rational way a flame war never is. I doubt that latter can be useful.</flame>



  • [quote user="Phalphalak"][quote user="ammoQ"]quote user="JCDenton"

     However, there does also seem to be a hell of a lot of flaming , counter flaming , personal attacks and insulting going on in some threads. You'd think there would be a lot of camaraderie in a community of s/w devs who all pride themselves on the quality of their code and who like to distance themselves from the script kiddies and incompetent. I haven't been a member for terribly long but I have read the forums long enough to notice this unattractive characteristic of the community. 

    [/quote]

    IMO, flaming and contraflaming are actually very usefull They help us to separate the things we are really sure of from the things that we do because they have worked in the past. If I cannot explain the advantages of PL/SQL over, say, Java and C#, it probably means that my only reason to use PL/SQL is that I know it well, while I feel wonky in other languages.
     

    [/quote]

    <flame>Hm, I think you are talking about arguing or discussing a topic but not flamming.  While a discussion may be led in a rational way a flame war never is. I doubt that latter can be useful.</flame>

    [/quote]

    <flame>No, it needs the infernal heat of a flameware to truly test your position. In a normal discussion, people tend to agree to differ.</flame>



  • *wonders when this discussion is going to turn into the argument clinic...*

     


Log in to reply