Stories
Slash Boxes
Comments
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

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Wednesday June 22, 2005
10:31 PM

The XP Ideal

[ #25323 ]
Extreme Programming is 6+ years old, and it's certainly been controversial. Many think it's impractical, unwarranted, or a wishful look at the way software should be developed. Others swear by it, or a related agile methodology. Others find themselves in the middle, and wish they could be on an XP team, or an agile team, or at least in a more agile group than they are now or were in several years ago.

Regardless of how you feel about XP, it has helped the industry because it has given us a goal and opened up a discussion on how to achieve it.

For example, take test-first development and refactoring. Test-first may be a controversial practice, but it has raised the profile of automated testing, which can improve code with or without any other XP practices. XP's love of constant refactoring may be hard to swallow, but it has brought a positive light onto rewriting nearly working code and replacing it with something better.

Today, I came across another example: pair programming.

At $WORK, I'm writing a parser for a rather complex and underspecified grammar in Haskell. This week, another wrinkle came up: the need to read and write Tcl-formatted strings. I'm sorta the research programmer on the team, so I'm pretty much on my own on this project. Which sucks, sometimes. For example, it's hard to bounce ideas off of a partner.

Again, XP gives us a model and a goal. With pair programming, one of the goals is to keep both a low level and a high level perspective in mind when writing code, rather than just one or the other. The model is to program in pairs, where one person focuses on the implementation details, and the other focuses on the larger level issues. Imagine my surprise when I started feeling some of the benefits of pair programming while programming solo.

Here's the trick: pairing $me[time()] with $me[time()+3600]. A couple of times today, I felt myself getting stuck on a problem without making any progress, I put it aside and pulled myself up to a higher level perspective. (Maybe that process took an hour, maybe less. I wasn't exactly keeping track of time. I'm sure some psychologist has an explaination on why and how you need to take time to switch perspectives.)

All of a sudden, my mistakes became clear, and it became obvious where I was hitting the wall. I couldn't see the way out exactly, but I could see the problem that was holding me back, and I got a vague feeling for where I needed to be. When I started diving back into the code, things gradually got clearer, until I hit the next wall. ;-)

I shouldn't have been surprised, but I was. There have always been times when I'm writing code where the best thing I can do is walk away from the keyboard. What did surprise me is that I found yet another instance where the best way to improve a non-XP process is to borrow a page from the XP book, ferret out the goal, and aim for it.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The three dogmas of XP you list - test first / auto test bases, refactoring and pair programming are those I find most useful from the agile methodologies.

    I don't really write my tests first, but I always do my best to have an automated testbench, that increases my confidence and allows me to refactor more freely, therefore being a productivity boon in general.

    Pair programming is also great in improving output.

  • That thing with changing focus from small-scale to large-scale is something I think is very useful and very important.

    Like the ability to not being stubborn about solving a problem that turned out to be too hard, or by doing it the wrong way. After a while you simply need to calm down and reassess the entire problem and see if you can solve it using a different approach. That's much easier when you have a co-pilot with a level head, but it can definitely be trained on your own as well.

    There is also the be
  • I used to hear grips that version control and software engineering practices were only useful on "large projects, or projects with more than one person," none of which were allegedly applicable to what we did here. However, I came up with the axiom that given enough time, any project appears large enough or appears to have more than one person. Come back to your code three months later, and it's like you're working with an older version of yourself.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • This last part is a bit like explaining it to the bear.

    Basic idea is you keep a teddy bear on your desk, or in a different room, and any hard programming task you get stuck with you explain it to the bear first. Inevitably you come to the solution during the explanation.

    Of course you look like a complete nutter - I'm sure someone invented this idea as a bet.