If I was to name one particular component at work that has been a burr in my butt for most of 2004, it would be CMS-BoB.  What in the heck is that, you ask?  A technical description really isn't necessary.  It's a piece that was developed and tested completely separately from the rest of the application.  Upon its initial deployment to production it managed to completely take down our application.  It became impossible for any user to log onto the site, and neither the developer who wrote the piece nor the tester who certified the piece for release to production could identify why.  What made it even more frustrating was that the exact same problem had cropped up in the development environment about two months earlier, and rather than identifying and fixing the problem they simply tossed in some debug-only code to bypass the problem.  A show of hands to anyone who is surprised that ignoring a problem during the development cycle might lead to disaster?  Yeah, that's what I thought.

After much wailing and gnashing of teeth, the problem was resolved and the component was sucessfully deployed to production.  Somehow.  A few months later that very same component knocked out one of the significant functions of the application for several days in production, and again neither the developer nor the tester could identify immediately what the problem was.  I have the sense that they are treating the configuration settings for that component as if they were some kind of magic ju-ju, and that if they just keep randomly changing them until it starts working then that's ok.

Two weeks ago I was handed a bug because CMS-BoB was not working in the test environment, and I was instructed by the tester to change the value of one of the configuration settings.  Since the value he was giving me was clearly a test environment value I asked him to clarify for which environments this change needed to be made.  He instructed me that that value should be used for all environments, which was absurd on the face of it.  He was in effect telling me that a test server would be the correct server to be used in a production environment.  In going back and forth with him it became leapingly clear that he had no idea specifically what was wrong, what specifically that key was for, or what specifically needed to change in order for the component to work.  He had just been told that that configuration was wrong and to change it.  Ultimately I figured out what the problem was (it was the key name that needed to be changed, not the key value), and the component began working again right away in test.

Last friday I was handed yet another bug related to CMS-BoB, in which there was a very clear error that precisely expressed what was wrong.  But in the text of the bug, this same tester had no idea what the problem might be and offered a few random suggestions that had nothing to do with the error.  For the record:  when you get an error saying that the user is unauthorized, you might try testing whether or not the user is in fact authorized.

At this point I have washed my hands of the component.  I have made it clear that I will not touch anything to do with CMS-BoB until I have clear documentation on the component, including what all of the configuration settings are, what the correct values for them are in every current known environment, and how to definitively determine the correct values for them in any new environment.  I have also requested evidence to show that there is a detailed test plan for the component which can be used in the future to isolate precisely where the problem is when it breaks again.  Finally, I have strenuously recommended that the component be removed from the application until such time that those things are provided.

I take a great deal of pride in our application, and I'll be damned if one lazy tester is going to take the whole thing down in flames.
.

Profile

lokheed: (Default)
lokheed

Most Popular Tags

Powered by Dreamwidth Studios

Style Credit

Expand Cut Tags

No cut tags