Friday, October 01, 2010

Think twice before modifying your process under the name of quality

I feel, more than ever, that I work in the same company Dilbert does. Maybe I do.

We just got another process coming, a Software Quality Team targeting improving our software quality. They provided a superb tool which searches for code snippets throughout all our Perforce repositories in no time, and ban any build that contains “known buggy code.”

This is not necessarily a bad thing, if you imagine how nice it will be if all known bugs are fixed before a release goes out. Because all releases contain all bug fixes, they must be “good”. They are going to apply this to every “bug” that is marked as highest priority, so the impact should be limited.
There was, as usual, no communication, no training, no documentation, just short emails sent to you as commands to follow.

I got 5 requests last week to provide a fix on different branches that we do not support. The integration teams create branches as they like and do not take new fixes from us the moment they branch out. This is okay as long as their releases are stable and customers do not complain. This is not okay if “I” have to merge code for them and warn them I cannot even compile for them. Each product has a slightly different build procedure and there is no way I can be expert for all of them, let alone testing for them. I don’t even have the hardware.

It’s bad to not plan for bug fixes but stop a build like that. Why, because the pressure to “make a build” is on the guys/gals at the bottom of food chain, who usually got very short dead line. All the requests I got are like, “I need a fix for this issue RIGHT NOW.” No test resources are allocated, and usually fixes would be taken as orphan files instead of tested, packaged, components. How much quality would you gain from this?

Maybe you’d be interested to know how critical that bug was. Like I said, our people are smart and they only do this on highest priority issues. How many levels of priorities do we have? Two. Almost every issue is marked as the highest these days, especially those comes from customers. I have to fix bugs specific to a certain customer on all branches, while we officially only support one branch. This is our concept of software product lines, I guess.

No comments: