Infinite Defects Methodology



  • Where I work we're split into client side (handle client-specific customization) and product side (focus on out of the box functionality). I'm on the client side.

    Recently one of my clients encountered critical defect 'A' in our product. Three weeks later a product patch (Patch 1) is issued that is supposed to fix defect A. It doesn't really help too much, but it does introduce critical defect 'B'.

    A couple weeks later, Patch 2 is released to address critical defect B. Today, I receive an email that Patch 2 (for critical defect B) introduced an even more critical defect 'C', so a new patch (Patch 3) is going to be released that will resolve critical defect C but reintroduce critical defect B. I'm assured another patch (Patch 4) to address critical defect B is forthcoming.

    On the bright side, I already wrote (i.e. hacked together) workarounds for A and B specifically for my client (since waiting weeks-months for patches to address bugs that need to be fixed NOW isn't really an option), so they're still sitting on Patch 1 + Hacks blissfully unaware of this clusterfuck.



  • At this rate the only sane solution would be to implement a hack that deletes your software's executable the next time it's run.



  •  See my sig.



  • One thing: regression testing?



  • @bullrider718 said:

    Three weeks later a product patch (Patch 1) is issued that is supposed to fix defect A. It doesn't really help too much, but it does introduce critical defect 'B'.
     @bullrider718 said:
    Today, I receive an email that Patch 2 (for critical defect B) introduced an even more critical defect 'C'

    How the hot holy hell aren't these picked up during testing?

    I can understand a patch that fixes a critical defect introducing one - or more - non-critical defects: that's progress of some kind. But expending effort to move a critical defect to another location is a waste of time and money.



  • Patch 4 consists of a zip, containing a single .cmd file, which reads "deltree -y c:"

    No more critical defects!



  • @Cassidy said:

    How the hot holy hell aren't these picked up during testing?

    One tester. Offshore.



  • @bullrider718 said:

    Where I work we're split into client side (handle client-specific customization) and product side (focus on out of the box functionality). I'm on the client side.

    Recently one of my clients encountered critical defect 'A' in our product. Three weeks later a product patch (Patch 1) is issued that is supposed to fix defect A. It doesn't really help too much, but it does introduce critical defect 'B'.

    A couple weeks later, Patch 2 is released to address critical defect B. Today, I receive an email that Patch 2 (for critical defect B) introduced an even more critical defect 'C', so a new patch (Patch 3) is going to be released that will resolve critical defect C but reintroduce critical defect B. I'm assured another patch (Patch 4) to address critical defect B is forthcoming.

    On the bright side, I already wrote (i.e. hacked together) workarounds for A and B specifically for my client (since waiting weeks-months for patches to address bugs that need to be fixed NOW isn't really an option), so they're still sitting on Patch 1 + Hacks blissfully unaware of this clusterfuck.

    I would not be the least bit surprised if you happen to work for our front-office sales software vendor.


  • Trolleybus Mechanic

    @skotl said:

    Patch 4 consists of a zip, containing a single .cmd file, which reads "deltree -y c:\"

    No more critical defects!

     

    I installed the program on the d:.  I demand Patch 5 to fix this critical oversight!



  • @Lorne Kates said:

    @skotl said:

    Patch 4 consists of a zip, containing a single .cmd file, which reads "deltree -y c:"

    No more critical defects!

     

    I installed the program on the d:.  I demand Patch 5 to fix this critical oversight!

    Why? It fixed the problem, didn't it?



  • @skotl said:

    Patch 4 consists of a zip, containing a single .cmd file, which reads "deltree -y c:"

    No more critical defects!

    Critical Defect E: Application does not run.



  • @bullrider718 said:

    @Cassidy said:
    How the hot holy hell aren't these picked up during testing?

    One tester. Offshore.

     

    Who clearly ain't up to scratch if they've missed these defects in separate patches. 


Log in to reply