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.
  • One nice bit about writing tests after the fact is that it's immediately apparent what needs to be fixed: it's usually hard to test. (The other nice bit is that you have tests. There aren't really any other nice bits for test-after development.)

    • No, no... writing the tests after the fact shows you what you need to push your billing up ... er ... to redesign :)

      As a side note, I think our experiment with XP is failing miserably. As of this writing, I am the only programmer out of four who is bothering to write tests. The others, while acknowledging the tests are important, don't bother with them much, if at all. We still can't get good story cards, we have no iteration planning and we're still stuck in an ad hoc development mode. We made a stab at XP and because we didn't seem to have enough buy-in to follow through, it's just not working.

      I sat down the other day and told my boss that I was completely happy to scrap XP entirely ... so long as we pick some project management system and actually do it. We don't seem to understand the concept of "follow through" and as a result, we're solidly back at step 1 of the Software Capability Maturity Model [cmu.edu].

      • Unfortunately, no software development method works if you don't have people willing to follow some sort of organized method. I second ziggy [perl.org]'s recommendation of Software Craftsmanship. Quality has to come from people who intend to do quality work. (Quality doesn't come from CMM, but that's another story!)