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

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.
  • I don't view [Extreme Programming] as particularly extreme: it merely says "follow the good programming practices that you already know about".

    Well, not everyone agrees that each of the XP practices is good. A lot of people view pair programming as a waste of one programmer.

    Extreme Programming is one set of good practices which have been shown to reenforce one another. There are plenty of other good practices, but if you cherry pick practices and put them together without considering how they interact,

    • The strongest objections to pair programming that I hear usually seem to come from those who have little experience with it and those who prefer to be alone. The objections, in fact, remind me of an interview where the manager told me "we don't want you writing tests because that will slow down your programming." I was offerred the job, but I declined.

      Having done quite a bit of pair programming here at work, I've discovered that it can be a bit tough as many programmers are, shall we say, not overly social. However, I've also discovered that a good pair can dramatically improve code quality and save many headaches. One pair tells the other "no, don't do that. We've already implemented it over there." Meanwhile, the other pair says "hey, you forgot to test if that's defined." When we stop pair programming, the team as a whole does seem to crank out more code, but we also wind up with more bugs slipping through, even with our tests. It's been fascinating watching how well our processes have validated many core XP tenets.