There was an amusing incident at work.
I'm doing QA. I filed a bug report. Someone fixed the bug. Then, someone complained that my bug report was invalid, because the code was right now! The code is on the server, so I have no proof that it ever was wrong!
I told the story to my parents. My mother's reaction was amusing. She said "How do you know it really was a bug?" She assumed, by default, that my bug report was wrong and the parasitic programmer was right.
If I were the owner of the business, this would be a firing offense. It's one thing to make a bug. It's another to lie about it and cover it up.
For some things I'm QAing, the answers are all NULL or all zero, which is obviously a wrong result. Their test data is lousy/wrong. I asked for better test scenarios, but they haven't created them for me.
I'm getting better at reading body language know. The body language of the developers is "I know this project is a disaster. I'm trying to cover it up." Of course, someone unethical like that is more likely to be involved in a project that's a huge disaster!
My direct coworkers are also doing QA. They are not the developers. They also have complaints about the quality of the code and output. I shouldn't be at any personal risk. However, it's always risky to be near a disaster.
Sunday, July 11, 2010
Rewriting History
Subscribe to:
Post Comments (Atom)
3 comments:
This is like having your bug report rejected as invalid, but then validated weeks later by microsoft quality labs. Why don't they ever recognize my brilliance?
I've come across something similar.
Two separate projects submitted source code at a similar time into a higher up codebase line stored in source control system.
Both projects altered some of the same functions.
Functionality was broken by this.
I fixed one bug. I think a colleague of mine fixed the other bug. We both tested and submitted our fixes.
Then an incompetent dishonest programmer came alone. He had a perchance for cutting corners. Instead of getting the latest source code out, he make a change to the source code after our fixes and then submitted them. His change had no real effect. He added code that did nothing. Of course if the guy took the latest code out and tested it, he would have noticed all the bugs were fixed. But he did not.
Alternatively he could have just asked us about the work. I noticed this guy refused to reply by email to anything. If I asked him to fix a bug in his work, he delayed and delayed, never got back to me and would just submit work that wouldn't even compile and not even give me a warning.
He then claimed he fixed the bug and that he was doing our job. He told management, who in turn berated me because this guy had to do my job.
In fact the bugs were fixed long before this guy came along, his fix did functionally nothing and if he had taken the latest source out would have noticed the bug had been fixed.
It suited management's purposes to have a fall guy, in case the project failed, but in fact the project was mostly successful.
It is difficult to know whether this guy was just incompetent (i.e. he really believed his no-effect code solved the bug that was already fixed) or dishonest (i.e. he wanted to take credit for out work).
It is a pity low-quality people like this manage to get into companies and even worse that they are believed over hard-working competent people.
By the way the term "rewriting history" is a polite way of saying LYING.
Post a Comment