nop has asked for the wisdom of the Perl Monks concerning the following question:

Any monks familiar with the "extreme programming" approach? There's a perl piece for unit testing here, but I'm seeking more general feedback about the entire methodology. Any positive or negative stories? Thanks.

Replies are listed 'Best First'.
Re: Extreme programming... in perl?
by chromatic (Archbishop) on Jan 09, 2001 at 09:29 UTC
    I'm studying it personally and professionally. (I'm reviewing the two new XP books for Slashdot and have spec'd a two article series, one of which deals with similar things.) My perspective is a little weird because it's half academic, half free-software-developer.

    I'm using Test::Unit (with props to our own clemburg) and doing the test-first, refactor mercilessly, write and complete stories approach with the Perl Rogue project.

    It's hard to gauge the whole XP thing with a single-man program, but it's promising so far. Writing unit tests before code is pretty different, but it's the only way I'd get good test coverage.

    The one thing I've noticed so far is that the combination of writing stories (to describe self-contained bits of functionality) and coding only as much as you need to pass the current test and complete the current story is improving code clarity and development speed. I don't have to plan for three or four different things at once. When I do come back to existing code, it's easier to make it more flexible (if necessary) because I have a specific and immediate goal in mind.

    It's also harder to break things without knowing it, because all of the previous unit tests that must pass before you're finished.

    This makes bugfixing easier, too, especially with multiple people on a project. A couple of weeks ago, I fixed a bug in Everything, creating another in the process. Darrick fixed the bug I created, recreating the bug I fixed. If I'd written a test to detect the bug I'd found, Darrick would have noticed it and come up with the correct solution immediately. (As he's a smart guy, he picked right up on it before I brought it up. But this could have been much worse.)

    Currently, I'm trying to introduce some XP principles into Jellybean development. Only time will tell how successful we are there. I'm not yet confident enough with Test::Unit to know how to write good tests for some of the hairier bits there.


      I hope you will write up your experiences about applying XP to Perl in a couple of months time. I'm currently just starting to play with Smalltalk as this is the XP language.

      However, if we can apply the techniques to Perl easily (and it works) then this would be very cool.

      Cheers! (And I'm off to look at Test::Unit...)

Re: Extreme programming... in perl?
by dws (Chancellor) on Jan 09, 2001 at 12:15 UTC
    (More info on Extreme Programming (the "other" XP) can be found on the original Wiki. There you'll find some early material from XP's originators, plus some interesting back and forth from the patterns community.)

    Over the past year I've borrowed a few practices from Extreme Programming for my own (mostly solo) Perl projects, with mostly positive results. The practices I've adopted are:

    • Take a project one "story" at a time, and
    • write the unit tests first, and
    • do "the simplest thing that can possibly work" to implement the story, and
    • refactor after each step, and
    • declare victory when all of the test cases pass.
    In XP, a "story" is somewhat similar to a "use case". It describes a chunk of functionality in the system, how an agent invokes it, and what results. Implementing a story typically involves designing and implementing a bit of each layer of the system. It's sort of top-down, but taken in thin slices. The trick is to only design and implement what you need for the story, avoiding the tempation to overdesign or overbuild.

    Writing tests cases first has a couple of benefits. First is that the test cases actually get done! My experience has almost always been that leaving test cases until the end means that they get squeezed out of the schedule, or overlooked in the mad rush forward. The second benefit is subtle: to write a test case you need to think about the objects you'll be testing, how they'll behave and interact, and how you can verify that they've behaving and interacting correctly. This is a very grounded approach. By approaching class design this way, rather than in some fanciful imaginative vacuum, you get testable classes, and method signatures that make sense to at least one client (the test case code).

    Next up comes implementation. "Do the simplest thing that can possibly work" says just that. Defer complexity until you actually discover (in some future story) that you need it, and do something simple (and correct) to implement the story in user story in front of you. If you're modifying existing classes, do the simplest correct thing you can think of to effect the modification. (Here's where having a body of test cases that cover prior stories really pays off. If you broke something, you get to find out right away, while it's still fresh in your head.)

    Refactoring means cleaning up the code. It's kind of like cleaning up the kitchen after cooking. Better to do it right away, so that you can start with a clean environment the next morning. More correctly, "refactoring" refers to a set of transformations you can do on code that maintain correctness. Discovering that you're performing the same operation in two different subroutines, and then extracting the operation into a new subroutine is one refactoring. (See Martin Fowler's excellent book "Refactoring: Improving the Design of Existing Code" for more info.) Here's where I force myself to find and resolve any #FIXME comments left in the code, and have second thoughts about using some neat-but-obscure trick picked up from PerlMonks.

    I've been using these practices for about a year now. The biggest problem I've had is fighting off the continual temptation to design ahead. On reflection, I have to admit that much of design ahead work I've done in years past has been wasted "premature generalization." I'd have been better off saving the code and investing that time elsewhere. But it is still soooo tempting to design reusable packages in my head before coding the parts that I actually need now.

    Along the way I built a simple yet quite effective test harness (applying the "do the simplest thing that could possibly work" dictum). It needs a bit of work to get it up to PerlMonks standards before I'll post it.

    And sometimes I take my Extreme Programming hat off for a round of Perl Golf.

Re: Extreme programming... in perl?
by clemburg (Curate) on Jan 09, 2001 at 13:50 UTC

    In my experience, the biggest problem is to persuade the organization you are working in to allow or even encourage pair programming. Most big organizations seem to feel pair programming is a waste of time (of course it is not!).

    In contrast, I feel that pair programming is responsible for the biggest change effects that Extreme Programming has to offer - better team work, more people "in the know", faster learning curve for everybody on the team, cleaner designs and code, less "quick and dirty" work, more fun.

    The other big thing about Extreme Programming is the emphasis on testing, obviously. But this has been there before - just read chapter 6 of The Practice of Programming by Brian W. Kernighan, or chapter 25 of Code Complete by Steve McConnell.

    Christian Lemburg
    Brainbench MVP for Perl

Unit tests as Clue stick
by dws (Chancellor) on Jan 09, 2001 at 23:26 UTC
    The other benefit of having good test coverage through unit tests: they can give you a whack with the clue stick, and tell you when not to be programming.

    On a two hour layover between flights earlier this year I fired up the laptop to get in a bit of coding time, and to try out some ideas I'd had on the first leg of the trip. After about 20 minutes of typing, I fired off my test driver, which at the time would run through about 40 test scripts, reporting whether each passed, failed, or failed to run. (Each test script covered several tests; giving an effective coverage of about 120 tests.)

    16 of the 40 tests failed.

    Pause... Think...

    Hm.. I hadn't eaten in a while, had just gotten off a bumpy flight, and was anxious about the weather on the next leg. Plus I'm sitting on the floor of the terminal in San Diego at one of the two available AC outlets, the place is packed with travelers, and kids are crying. Maybe this isn't the best time to be coding... If I keep going, I'm just going to add a bunch of bugs that I'll feel compelled to fix on the next flight, at altitude, where the air is a bit thinner and my brain won't be working as well.

    Back out the changes, shut down the laptop, and trundle off in search of food.

Re: Extreme programming... in perl?
by knight (Friar) on Jan 09, 2001 at 20:11 UTC
    Like others, I've not been able to get any organization with which I'm involved to bite off on some of the more eXtreme aspects of XP, such as pairs programming. The aspects, however, that I've adopted for all my own projects are the testing+refactoring.

    Amplifying on dws's comments above, once a project grows beyond a certain size, it's the fact that I have all of the unit tests as a regression test base that enables me to refactor effectively. Before becoming converted to writing the unit tests first, I'd always reach a point on a project where I knew that certain internal subsystems needed to be completely rewritten, but rewriting them was usually painful because it would take a lot of by-hand testing to try to make sure I hadn't broken anything. And even then, I'd often not discover that my laborious ad hoc testing still missed some end case until the code was in the field...

    With a good set of tests created incrementally during development, I can refactor and know that I haven't broken an interface. And if the tests are still missing an end-case and a bug slips through the cracks, well, another test gets created when the code gets fixed, and that's another situation that's guaranteed never to cause a problem in the future.

    This makes the whole development cycle more productive than I had ever imagined. Very powerful, and very addictive.
      I'll jump in here with a small comment about paired programming: it's awesome. Fortunately, my current work place really encourages it. I was kind of iffy about the whole idea at first, but I've changed my mind completely since I started seeing how much better my programming is when you combine two minds. You catch a lot of assumptions & get exposed to a lot of different ways of seeing things. One big bonus, too, is that a lot of different people become familiar with different areas of code. So if something breaks, you have a larger pool of people who can fix it.

      The only problems we've run into are that some folks type dvorak & some type qwerty- there are always pairs forming where only 1 person can actually type faster than 1 letter a minute on the keyboard being used. (;

        Buy USB keyboards and plug them both in. or alternate. USB makes me extremely happy these days. =)

        $you = new YOU;
        honk() if $you->love(perl)

        actually we had the same problem with keyboard layouts until I discovered a solution...if you're using Windows as your workstation (I'm sure you can do the same thing for Linux workstations, too, I just don't know how) you can go into the Control Panel and hit the Keyboard icon. From there you can add new layouts from the Input Locales tab. So add either Dvokak or Qwerty depending on what you don't have.

        Once you're done, at the bottom of the "Input Locales" is a hot key selection which allows you to switch layouts on the fly on a per-window basis. So my partner and I often switch and hit Left Alt+Shift to switch between layouts on our terminal windows. It makes pair programming much easier.

Re: Extreme programming... in perl?
by petemar1 (Pilgrim) on Feb 12, 2005 at 19:08 UTC

    While I personally haven't used XP regarding Perl, ExtremePerl exists.