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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

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

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday January 20, 2004
11:40 AM

XP Unfactored

[ #16920 ]

After having worked at my present job for a few months, I decided it was time to reread chromatic's excellent Extreme Programming Pocket Guide (disclaimer: I was a reviewer for that book). I've come to the conclusion that our company has mixed up flour and eggs, thrust the bowl forward and said "Let them eat cake." (i.e., we claim to be XP though we only follow a few practices.) Our pair programming is sporadic. Our refactoring is sporadic and there's a tendency to write the tests after the code and accept that they sometimes fail.

I could go on about the number of things that we don't do, but I won't. Instead, I'll focus on the positive: we have some awesome developers. We get requests from our customers in Los Angeles, we estimate how long it will take to accomplish those requests and we negotiate on which ones will get done. Then we write the code (sometimes in pairs), write the tests, turn it over to QA and then check it into production on a one-week iteration. It's really not a bad system and, in fact, this is far and away some of the best Perl code that I've seen in a project this size. Still, I find myself wondering if "good enough" is good enough. Can we do better? I'm particularly worried about the lack of constant refactoring and the "oh, that test sometimes fails" attitude. In my upgrade to 5.8, I've rewritten every intermittantly failing test to ensure that nothing fails unless there's really a bug. Unfortunately, the 5.8 branch sits and gathers dust while we wait for our other projects to wind down before we can upgrade.

I'm going to have to do a lot of thinking about XP and how it applies to our shop. Frequently, our customers want something and we just say that they'll get it, but we don't always make firm promises when. The programmers are conscientuous, so we're not taking advantage of them, but sometimes we do get angry calls from the president of [insert name of large Hollywood studio here] because our communication channels are not what they could be. XP, like so many other project management systems, is ultimately about communication. While we're hit and miss on that, we still do a good job. This is a good company to work for.

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.