Code-smell: Whack-a-Mole
It’s 4:00 on Friday afternoon. Do you know where you want to be?
Definitely not at work. About fifteen minutes before you decide to log off and bolt out early, a critical defect is logged with your application. Your data import isn’t working correctly and it is losing content during execution. The client, and project managers stress to you that this is a must fix issue as the testers cannot continue until your content is valid.
You grumble, sit back down, and pull up the code to inspect the issue. Ten to fifteen minutes later the fix looks relatively easy. Excited that a resolution was identified so fast, you settle in and begin the fix. Shortly after the fix is in place, you test to make sure everything continues to work as is…. then you gasp as you realize what happens next: it is the Whack-a-Mole bug.
whack-a-mole bug n 1. a defect that reappears throughout your application in multiple locations and is difficult to get rid of no how many times you attempt to get rid of it
Related Code-smells: DUPLICATE CODE, SHOTGUN SURGERY
Most often this code smell is a by-product of Shotgun Surgery. While it may seem easy to copy the same validation code used during data-in to data-out, you know it is not the right choice. Now later on, that specific code had particular issues and it must be fixed in more than one place.