We had a relatively disastrous prod deployment last week. Four bugs, caused by a large refactor, were missed in test. But here’s the weirder part, along with those four bugs, the users started reporting previously existing functionality as new bugs, and in some cases, convincing us to do emergency patches to change said previously existing functionality.
It seems bugs beget bugs.
Apparently the shock of these initial four bugs created a priming effect, which resulted in overly-critical user perceptions:
“I’ve never noticed that before…must be something else those clowns broke.”
I’ve heard people are more likely to tidy up if they smell a faint scent of cleaning liquid. Same thing occurs with bugs I guess.
What’s the lesson here? Releasing four bugs might be more expensive than fixing four bugs. It might mean fixing seven and dealing with extra support calls until the priming effect wears off.
RSS
You nailed it with "overly critical user perspectives". I've seen similar situations occur, even on features that had been previously user tested and passed.
I think we are about to experience something similar here, with a release to an internal application that includes an updated look and feel to one specific function. The difference here is that I believe the new features will highlight some of the deficiencies in other parts of the application. Something that people were not necessarily effected by; with the clunky, old interface; is now glaringly obvious with the new, improved interface. When the "issues" are pointed out we’re told, "But that’s not part of this release". While it’s technically true, I think we will experience a rise in calls and issues reported for existing issues, much like you describe.
LOL and deja vue. I have seen this effect quite a bit. At first it caught me off guard. As I dug deep I found 2 factors coming into play:
1-Historically IT has acted like "clowns" when delivering software. Late, over budget, 60% of requested functionality, application riddled with bugs; not a good way to build a reputation.
2-Agile promises higher code quality. This results in business folks not feeling a need to test. After all, there are no longer any bugs being delivered, right?
When code is delivered with bugs the business falls back into the "same old routine" where they feel it is necessary for them to test because IT is delivering poor quality software again. The result of this increased level of testing is dormant bugs now come to life. Enjoy this new found state because it will be with you for a while.
Good luck, Tim. Or "brace yourself"!
At first I was torn. What's the best dev team reaction? Do we push back and say "that's not a new problem, it was there all along and you didn't complain about it until yesterday's release".
In the end I went with something my father (small business owner) taught me long ago: The customer is ALWAYS right.