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?
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?
For further actions, you may consider blocking this person and/or reporting abuse
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?
Yes, it for real.
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?
Yes, It's exactly why I have my doubts. It's not an error free profession.
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!
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.
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.
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!
Best answer
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".
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:
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.
Seek to learn, not to blame.
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/
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.
Hi Camilo,
While reading your other articles I stumble upon this post, and I have something to say on this as I had faced this in past.
My experience was not good about this strategy in past but it helped me to take important decision i.e to leave job.
While doing creative job like coding , bugs / errors happens , and to be frank sometime while working with new technology it happen a lot which gradually over time get perfected but only if a developer get a chance to improve skills, if the developer get penalized like this, developers thought get limited and focus on writing less codes and less scope the code to minimize bugs, I remember around 5 years ago my entire months salary get deducted due to this and which make me think to leave full time job which was the best decision of my life.
So accordingly to my past experience, it is very good practice if employer don't want developer to work freely and encourage developer to look for job somewhere else, and it's a bad practice of employer if employer want developer to work in peace.
Having said all that, I have also seen in some teams it's just for fun, those are fine, until if someone life and means of living not getting harmed, there should be no issue.
Hope I am able to express my past experience properly.
Thank, is good read it from some one who past through this.
This isn't just a toxic practice. It's illegal in some states: avvo.com/legal-guides/ugc/can-your...
I have not heard of that myself and find probably somewhere between doubtful and utterly wrong.
If very small amounts of money are collected (i.e. 1-2€) and they are used to buy pizza, beer or cake for a release, I would still find this approach doubtful, but could see a point to sharpen the view of everyone to good code and in the end it's used to have a small release party.
But as you wrote, this can distract from fixing the issue to either hiding mistakes or arguing if this should be accounted for. This is not very helpful for code quality, team morale or pretty much any other positive aspect.
Btw: was this introduced by a manager? How much does he or she pay per day to day mistake that happens? I think this counter question shows how absurd this is as management method.
It was mentioned by tech leader because QA report same mistake over and ever again (on differents screens).
They talked, the whole team and agre this "taxes":
Money collected wold be used for buy beer on December.
As the tech leader fee is double the price, it might be worth looking at, as the money goes into beer for the team in the end. An even softer approach would be to just give points and the person with the high score has to bake a cake in the end.
As long as this is done in a fun way with a little wink and not to but blame individual persons, it could work. As soon as it becomes a real punishment or could cost a developer a relevant part of the salary, it will get very serious and can cause more trouble than it actually solves (in my opinion).
Holy 💩, you should call to them in a public manner, that is ... so ... wrong.
First of all there is no software w/o bugs, it is just a matter of not discovering them.
If the amount is significant I could imagine a lot of negative side effects like
If the amount is symbolic it is a "wall of shame", which may have the same side effects and more on the social side.
Maybe they should focus on a "no-blame" and make the company learn how to stop having that bug in the future. What have they done to fix it, how it was found, what can be done to never see it again.
I have never heard of this approach before but I don't think it's a good practice. Sounds a kind of blame culture approach. I don't think is the way to go. Probably the team / company can find other mechanisms to make their deployments more robust (testing [unit, integration...], code coverage, stage environment...) instead of punishing paying money. At the end, people is the most valuable source of a company, let's take care of them!
I assume that only developers are subjected to this policy and everyone else is free to make mistakes as they happen.
It is important to know that as humans, we are pretty flawed so it should come as no surprise that mistakes are made but all we can do is our best to rectify them.
Punishing someone for making mistakes can only go one of two ways, it will make them better at finding ways to avoid punishment or it will amplify the rate of mistakes tenfold.
I've never heard of money been collected. What I have seen happen is the dev been held responsible in a few ways:
Publicly shamed within a larger meeting and/or put on a wall of shame for the week/month
Developer's review and bonus were affected significantly
The developer was put on pager duty to wake up in the middle of the night and handle live-site issues.
Places like Amazon make every developer responsible for their own features and are put on pager duty for their feature
I don't think any company should be collecting money from their employees for bugs.
I have never seen this practice as company rule or politic, I think would be something illegal retain salary money. It's more like team's agreement.
But after read your answer, I prefer collect money than this first item, it's scary.
That seem incredibly counter productive,
you don't make mistakes only if you don't do anything.
More over any major feature or major refactoring prone to have bugs.
So if someone would tell me that I will have to pay for bugs if I have another option quit on the spot and if I don't(lets say its North Korea and only government have computers) do the absolute minimum to avoid been penalized.
Seems like a pretty bad work environment.
Altough I have heard of teams where the dev who broke the nightly build had to buy beers for the team. That is a fun little game and boost but being shamed for having bugs is a big no no in my book
A token fee, like a dollar contributed into the team bug jar? That can be good incentive.
I've heard of Scrum teams using the trick to curb tardiness/absenteeism to the daily Scrum stand-up meeting.
A punitive fee, like a day’s pay? Nope.
On a related note, for one project I was on, if any dev broke the build they were obligated to bring in donuts for the team. Mmmm, donuts.
I am not in favor of any of the above.
If this was a small amount of money in a way that was sort of "for fun", I think it would be okay. If it seriously impacted anyone's income I'd say it's bad practice for sure. All systems end up being optimized for and gamed and I really think this would be ripe for this sort of thing.
While maybe not one-to-one, this has Cobra Effect written all over it.
Yes I see it's a small amount of money, something symbolic.
Sounds like the developers would have a financial incentive not to innovate or improve anything at all.
Writing blameless postmortems, and realising that everyone makes mistakes creates a culture which embraces the fact that we are human. In a situation like you described I'd just avoid writing code so I write less bugs so I can't see that being realistic
Completely agree!
The fact that devs are arguing whether something was a bug definitely is a red flag that this system is bad for the team, and the organization as a whole. It seems to me the problem is deeper than just devs making mistakes, so it probably won't be fixed by penalizing them. If the org is serious about quality, then they should probably examine whether the software is designed in such a way that devs can produce bug free code.
The practice itself is definitely borderline. I suppose it is similar to a "swear jar". In the dev context, maybe that could be making the same common mistakes over and over. The "bug jar" would really only work if the group agrees it is a problem and wants to take that step as a learning reinforcement aid. Trying to inflict it on the team through management would be absolutely horrible.
Here are my two cents.
It is not right not normal. Mistakes should not be punished, and bugs represent feedback.
If there is some technical debt or a misunderstanding of the requirements, you want your system to get that feedback, the earliest the better.
It is not good for the team nor the product to be shamed for a mistake you made six months ago.
A better culture is one where knowledge is encouraged, you should try to learn from those mistakes and share that knowledge with the team and/or make it available.
Insulting and toxic at best, No one should expose themselves to such horrible practice and working environment. I hope this horrible approach fade in time.
This is not normal at all. If it is anything, it's the opposite of normal. Please look out for a better team to work with.
I try not to be too heavily opinionated on this site (which doesn't always come that naturally!) but on this matter: NO.
That's a terrible idea. The worst. No. Never do this.
Also: No.