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 ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
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 July 20, 2004
12:15 PM

Oh! Pair Problems

[ #19955 ]

You may remember my previous post about pair problems and my pointing out how we've stopped much of our pairing and our bug rate hasn't gone up.

Let's just pretend I never said any of that. Regrettably, our bugs have evolved and have learned to crawl deeper underground and are more difficult to root out. Superficially it looked like we were getting more work done and, initially, I think we were. Somewhere along the way, though, things started breaking down and in the space of only two weeks the programmers have requested that we slow down and go back to pairing and management has agreed. Despite the agreement, we're not pairing and the workload doesn't seem much slower, but we're still struggling to find the best way to get work done which satisfies everyone. It's clear that we're still turning out a lot of work, but failure to spread business knowledge has been what's really biting us -- hence the bugs.

I suspect that management is either going to have to babysit us through this period (which I doubt they will) or we programmers will have to find a way to work it out amongst ourselves.

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.
  • Let's just pretend I never said any of that

    I have to admit that I snickered slightly when I read that. Sorry :-)

    Despite the agreement, we're not pairing and the workload doesn't seem much slower

    I've found that moving to shorter iterations for a bit can sometimes help with this. It forces you to make the stories smaller, which means that people get to work on more stories in the same period of time. The more different stories you get to work on, the more domain knowledge you need to cover, so you h

    • We have one-week iterations. We've wanted longer ones, but I think that shorter iterations have been a benefit when we get a bit sloppy.

      • We have one-week iterations.

        Scratch that advice to try shorter iterations then :-)

        We've wanted longer ones, but I think that shorter iterations have been a benefit when we get a bit sloppy.

        That's been pretty much my experience. Longer iterations work well if things are going okay, and moving to shorter ones helps when there are problems.

  • If there's any sort of quantitative incentive for knocking off bugs--even if it's indirect incentive such as bragging rights--the easy bugs will go first, and the harder ones will tend to get avoided until they're unavoidable.

    Have you tried treating bugs like any other story? Let your customer (or customer proxy) prioritize them and decide which go into the mix for an iteration. This has the benefit of keeping a single set of priorities, and helps avoid cherry picking on small problems, or playing hot p

    • It also lets you put the time spent fixing bugs into the "how's our estimating?" feedback loop./p.

    • We do treat bugs like other tasks. The only major exception is bugs that affect the availability of our site or our data inputs/feeds. Those are almost always "drop everything and fix them now." Our data is what we get paid for (the Web site is a free bonus to many of our customers) so we can't afford to drop the ball there.