3

In a team that I used to work for, there was a policy that if you introduced a memory or other resource leak, you got a 'dummy of shame' hung on your door until you found the next resource leak.

While it was effective at finding resource leaks, I felt like it placed more emphasis on blaming others rather than working together to solve problems as a team.

Am I being unreasonable in thinking that this policy contributed to a lower sense of team cohesion? Am I also being unreasonable in thinking that we should have rewarded those people who found and fixed the issue?

1

4 Answers 4

4

Your dummy of shame will actually result in your bugs getting fixed slower. People just being people, they will have a secret backlog of bugs so when they get passed the dummy, they will "miraculously" find another developers resource leak before the day is over.

It's all about incentive, your policy does not promote finding leaks, it promotes finding 1 leak, and that's the leak you find right after you got passed the dummy.

Also the fact that it stays with you till the next leak is found means that the "punishment" has nothing to do with the severity of the bug. Someone can make a big resource leak, have the dummy for a day, find a tiny issue the next day, pass on the dummy and it may stay with the one who made the tiny issue for longer then the guy who made the big oops.

1

I do not think you are being unreasonable in thinking that.

As the idiom goes You can catch more flies with honey than with vinegar

We are not perfect, people make mistakes from time to time and rather than focus on blaming someone then publicly shaming them, It would be in the team's best interest to have the bug fixed as fast as possible rather than ship failing code.

To mitigate the loss of sense of code ownership that might be brought by doing this pro-team move, you can place restrictions that the owner of the code where the bug originated from still has to fix it on his/her own UNLESS its a bug that is beyond the programmer's capability to fix.

As for reasons why bug bounties or incentives, check out MichaelIT's comment.

0

It is important to differentiate between 'bugs' and 'code quality'.

Bugs are unavoidable when developing software, so attaching a negative stigma to bugs is, in effect, attaching a negative stigma to creating any new code. It is typically better to manage the overall code development process. A more efficient process could cause those bugs to be caught at an earlier stage of development, and could enable a better response time to remaining bugs that are discovered later.

To start, examine the development process and identify areas of confusion, which could include:

  • Business requirements "X should be able to perform Y"
  • Technical breakdown of the business requirements (services affected, ui needed, acceptance tests)
  • Coding standards, tests, style (to some degree)
  • Frequency of code commits
  • Ability to fix bugs before writing new features.

If there is a culture of fixing bugs before developing new features, would there need to be a 'policy' surrounding bug fixes? If developing quality code becomes a natural process, if fixing bugs becomes a natural process, then the need to make policies and reward systems will be lessened.

0

Apart from the premises of the question, how same question (about the unreasonable thinking) applies to a classroom teaching:

Imagine two teachers who both frequently makes class participate by asking questions like "Does anyone know the answer?"

When students in classroom raise hands they might know or not know the answer, or hit the point anywhere between. Lets focus on the "not so right answers" that are picked.

Teacher One would approach it with the "dummy of shame" approach. If the answer is not correct, or very close to correct... The student is ridiculed with "How poor answer, shame on you."

Teacher Two would approach it with encouragement. When the answer is not correct, everyone are encouraged with "Good answer, it explains X and Y about the question but there is more." (then continuing to explain it, not asking anyone to "correct" the first answer because it would create competitive environment.)

Now think which one of these teachers have more hands raised when asking question like this. Teacher Two creates an environment where everyone can participate without fear of not fully understanding it.

This can be applied to original question. In team programming everyone are participating, which should be encouraged. When memory leak bug is found, like another reply stated, making bug creator fix it by offering support creates learning experience and lead to less such mistakes made in the future by this programmer. It is also more likely that everyone are more willing to participate and work as a team, not working as "pack of competing predators".

Not the answer you're looking for? Browse other questions tagged or ask your own question.