DEV Community

Camilo Martinez
Camilo Martinez

Posted on • Edited on

Is it good or bad practice to make developers pay money for his bugs?

I see this practice on several teams, but I'm not sure if really works.

For me cause more problems because the team focuses his effort on the fight about the bug with QA and less to solve it.

Someone has used this strategy?
Money was collected for?

Top comments (38)

Collapse
 
dhnaranjo profile image
Desmond Naranjo • Edited

I'm pretty early into my career as a developer. I'm also pretty ambitious in my independent learning and my ideas for improving the application I work in.

Many of my experiments are beneficial. Others are interesting. Some are authentically bad, but I learn from them. Occasionally I push new ideas that, at first inspection from my coworkers, pass muster and make it into production before manifesting issues. Usually these issues are minor. Once or twice they are more significant.

We have decent test coverage, a fairly regimented pull request review, and qa process. If I, or a coworker, commit some bad code we identify a failure in the process and discuss it.

The idea of being penalized monitarily, or shamed publicly, or being subject to any punishment or retribution for making mistakes in good faith is so unacceptable to me that I can't even imagine my reaction.

Is this a real thing that people do?

Collapse
 
equiman profile image
Camilo Martinez

Yes, it for real.

Collapse
 
dhnaranjo profile image
Desmond Naranjo

This industry pays too well for anyone to accept a job where a person is treated like that. I gotta ask the theoretical strawman developer who gets admonished for trying and failing, where your dignity at?

Thread Thread
 
equiman profile image
Camilo Martinez

Yes, It's exactly why I have my doubts. It's not an error free profession.

Collapse
 
dmfay profile image
Dian Fay

I could see it not being a complete disaster if it was a token amount paid into a team lunch fund or as an occasional fundraising gimmick for charity or something but no it's still a terrible idea. People have debts you don't know about, it'll turn most prospective new hires off on principle, and like you've noticed it sets cultural priorities in ways that don't do much to help team cohesion.

I've done an "I broke the build" trophy before. That's all in good fun though, less about shame and more memento mori -- it's coming to you eventually. Plus, everyone has the same goal: to ensure the current holder keeps it as long as possible!

Collapse
 
kaydacode profile image
Kim Arnett 

Sounds like a terrible work environment.

We are human, not machines. Mistakes happen. The important thing is that you learn from them, and recognized where the failure came from and fix it for future iterations.

You learn from failure, not success - is one of my favorite motto's I've heard floating around.

Collapse
 
flexdinesh profile image
Dinesh Pandiyan

I would agree if I get a share of the money my code makes.

Jokes apart, this is toxic. If we start grading devs for the code they write rather than the value they bring to the team and the project, then we're not moving forward, we're just writing good code that amounts to nothing.

Collapse
 
lewiscowles1986 profile image
Lewis Cowles • Edited

It is one of the stupidest policies I can think of and only seems to be a way out of paying a bill.

If you ask a dev to add two numbers, most will present you with a solution. You'll have no bugs because complexity is so low.

If you ask a dev to do something that already exists they will probably use something that exists. You'll inherit all of the bugs of that thing (and there will be bugs in EVERYTHING regardless of if your team has the brains to find them).

If you ask a dev to do something that has never existed before they may use prior work to support that (thereby inheriting the bugs), they'll be specifying new domains (and there lurk bugs because it's by it's nature new and exploratory).

If you run a business with zero bugs, you're just too stupid to work with. Too Stupid to know there are bugs and edges and places your code, processes and staff won't be the right fit because no business or person has infinite resources.

If you strip your coders of revenue, which in my experience they spend managing health, psychology, CPD (because none of your budgets are that good). How do they meet your growing list of demands?

It's as much nonsense to remove money from someone you want to keep helping you as a physical attack on them. How can they help you when you're distracting them with other nonsense?

Even if you would prefer they left and you found someone else to help you, pay them. You couldn't walk to a shop as a reasonable person (please nobody highlight yourself as a cretin) to complain that the food you ate didn't measure up to your caloric or other needs.

In life sunk costs are those it's best to forget. Don't burn your money and encourage others to, trying to work out how to burn less money. Accept it's gone and look to move on giving actionable feedback, requesting deeper insight and perhaps involvement with process.

I will never apologize for bugs. I'll never feel bad I write them, and I'll always feel good when they are discovered because it's something else to keep my mind and wallet busy. Take away either my mind or my wallet and I'll go work elsewhere. I encourage other coders towards this too!

Collapse
 
diegoangel profile image
Diego Rivarola

Best answer

Collapse
 
scottishross profile image
Ross Henderson • Edited

I can't even comprehend this, so my two pence are simply: I would never work there.

It actually reminds me of Milgram's Experiment, at the least the blind experiment. "Shock some people if they're wrong".

Collapse
 
erebos-manannan profile image
Erebos Manannán • Edited

Any workplace trying to publicly shame people in any way with swear jars, penalties for bugs or anything like that, does not deserve any respect. I would never work for a company so badly mismanaged.

Two golden rules of feedback:

  • Give praise publicly
  • Give negative feedback in private

Also bugs happen to everyone, it's stupid to punish anyone, or even give them negative feedback for it. Hell it's stupid to waste time figuring out who to "blame" for it.

Just fix the bug, try your best to avoid the same bug in the future, and see if there's anything you can do to improve your processes and ways of working to prevent that class of bugs from appearing in the future.

Collapse
 
val_baca profile image
Valentin Baca

Seek to learn, not to blame.

git config --global alias.learn blame
Collapse
 
buphmin profile image
buphmin

I would no say know unless its a contract type job, and even then probably not. People make mistakes, keeping it light-hearted is best I think for work. Fostering a pleasant work environment is important as turnover in software is pretty costly.

If a person is a common offender then they need to fix the problem or be removed. That and raises should reflect performance.

\m/

Collapse
 
darksmile92 profile image
Robin Kretzschmar

I never came across such a "strategy" and I am a developer for almost 10 years now.

My opinion on this is clear: such a rule makes things worse and leaves personal evolvement behind!
What do you accomplish with it? Emotionally this causes more mental stress and pressure on the developers which is bad for their well-being (physical health and satisfaction with their work).

Also they will be focused on getting their stuff done without bugs first before helping others out => bad for the team and learning.

What you want to emotionally trigger in the developer are feelings of happiness when there are few bugs.

We do the following:
Bugs are tracked automatically due to Visual Studio Team Services (we can get statistics from there easily). For each iteration until deployment, every developer should not have caused more than 6 bugs. Exceptions are bugs because of unclear specs (this has to be handled in the team that they discuss it before starting dev next time). If this goal is reached, the gets rewarded with a dinner or some other team activities.

Important part: If the goal is not reached, there is no punishment!

This makes the whole team want to reach the goal but no one must be afraid of punishment for not reaching it and the communication between us is better than before.