Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I don't regard XP as a single, monolithic set of practices. All of its parts individually make sense, and they enhance each other, but I don't see a reason that they're all required during every phase of every part on every project. The single most important practice, in my observation (but not experience), is test-driven programming. All else is somewhat optional, or at least flexible, depending on the scope and size of the project and the rest of your methodology.

    XP to me seems much like many assertions

    • I definitely agree with the much of what you say, but I am concerned about XP in general. Pair programming is code review -> don't do too much refactoring without code review -> don't do the refactoring without tests ->don't write the tests without a clear understanding of the what the task is, etc. Pair programming is also knowledge sharing -> with knowledge sharing and more tests, we can write less documentation. XP seems to create certain chains of events that, if not properly understood, can cause people to stumble when they miss some of the links.

      The refactoring link might be one of the biggest failures. The design cannot efficiently "evolve" from the code when refactoring isn't being done properly/consistently. I've had to deal with tedious objections from programmers who fail to understand the "don't duplicate" rule. They argue (sometimes correctly) that too much abstraction can detract from the task at hand, but fail to realize that eliminating duplicated code, when done properly, leads to greater clarity rather than greater abstraction. I was also stunned when people objected to me removing many modules with structures as follows:

      package Foo::Bar;
      use base 'Foo';


      Those were all over the place because the intent, over a year ago, was to fork the code, but now those were simply useless barriers to further development, had duplicated tests (oh, for inherited tests!) that had to be maintained, but kept 'em because people were afraid of what would break if they were removed (I thought the tests were supposed to add courage for doing the right thing?) I managed to remove them one day by simply doing it as part of a task to "improve performance," but I'm still surprised that people actually wanted that mess. As dws pointed out, though, much of this is due to XP being imposed from the outside on many developers. If they really trusted it, I suspect we wouldn't have some of the silliness that we do. We're so close to having a team that really shines, but that final coat of polish seems to be lacking.

      • Again, the biggest issue is quite clearly test-driven development. Your coworkers do not seem to have understood why they should write tests. Consequently, they're seeing them as a burden, writing woefully inadequate ones to claim they're done. Inevitably, they have no courage to refactor cruft. It is all pretty obvious, if you ask me.

        I really believe that once a programmer understands in his heart why test-driven development is A Good Thing, then all the other practices of XP will be understood effortles