- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Admin
Does that make THOSE clauses right? Those clauses were once put in there so they were not easily attainable. It was for the career .270 hitter who might hit .310 that year. It was more to get the player a nice bonus if he outperformed expectations.
Actually I believe clauses based on individual stats are not allowed in MLB anymore (bonus for over 50 homers is not allowed, for winning the world series is ok).
I can't think of a single instance in the NBA where there are incentive clauses (like they need it since the contracts are so out of whack in that league, no middle class, rookie contracts or max salaries pretty much).
NFL has started to include these but they can effect the cap in weird ways. They have the expected attainable bonuses which then get paid off in the next NFL fiscal year. It is a complex system.
Admin
How will the pricing be determined? By age of bug? I can easily see that turning into its own black market of not doing anything for a few months until there are enough bugs to open the market.
/It's a better deal than the "Milestone Discretionary Awards Program" at a former job. Basically, "work overtime doing other peoples' jobs and n number of you will get bonuses for x[/x] amount of money." In the end though, there were only [i]n/2 awards given out because most people were smart enough to participate. Unfortunately I was the (n/2)+1th person naive enough to participate.
Admin
Admin
There was a similar suggestion from a former CEO of mine. He suggested to the executive team that he would base developer bonuses on ...get this...the amount of code they wrote. Literally paying bonus based on the number of characters and lines in a developers code.
I don't know about you, but I can make "x = 1" turn into a 3 thousand line file if I'm getting paid enough.
Admin
Problem is, that's so hard to define that you'll end up with it either being over-used or not used enough. People will either expect it or resent it. The system described is actually better, as it sets a specific objective to be met, which people can work towards, rather than a "Make my manager like me" issue, which will probably lead to burnout or more corruption.
Admin
That would be Rich Rodriguez. I graduated from (guess which school ;) ). He's a complete sleaze-bag. If he wasn't scamming the school for more money, he was sleeping with the students and betting against his own team. Such a stand-up guy... Of course, the school was more than happy to oblige because, hey football brings in the big bucks right?
Admin
[quote user = "Snoopgr2"]I don't know about you, but I can make "x = 1" turn into a 3 thousand line file if I'm getting paid enough.[/quote]
package umaintainable; class Verify{ boolean isTrue(boolean assertion){ if ( assertion != false ) return assertion; else return assertion; } }Admin
Yesss... I can see you are beginning to understand. Now strike me down and your journey to the dark side shall be complete!
Admin
I have to agree, i like this system a LOT.
Admin
-Harrow.
Admin
Except that would / could change exempt (salaried) vs. non-exempt status (hourly); not as simple as it sounds.
Admin
Sounds like when the concept of "fire insurance" was introduced into Ankh-Morpork.
Admin
It's killing me that I can't think of where this is from.
Admin
This (mis)management technique was mentioned in the Dilbert Principle, circa '95.
a quick google reveals this quote:
A manager wants to find and fix software bugs more quickly. He offers an incentive plan: $20 for each bug the Quality Assurance people find and $20 for each bug the programmers fix. (These are the same programmers who create the bugs.) Result: An underground economy in "bugs" springs up instantly. The plan is rethought after one employee nets $1,700 the first week.
http://users.rcn.com/alderete/humor/norm/dilbert-princ.html
Admin
I do believe it's a Winston Churchill quote.
Admin
It's paraphrasing Winston Churchill
Admin
I think you would just wind up with people doing absolutly minimal work, just enough to get by, for fear of introducing bugs.
Admin
Maybe you wouldn't do it intentionally, but unconsciously there would be one less reason to ensure the code you checked in was perfect.
Admin
lightsaber ignites Done, and done. vwoom
Admin
8 year-old boy goes to his father with his homework:
(a few minutes later)
Admin
I'm going to write me a minivan...
Admin
You could have a secondary market allowing other developers to guess the future price of a fix, based on their assessment of the complexity. For instance, developers decide that the Paula Bean module rewrite will take 6 months, but another developer believes the project will be cancelled, and so is going to be 'short' on that bug.
In all seriousness, if they're worried about developers/testers gaming the system, they could have a weighted system such that the bonus diminishes with the number of bugs fixed. That way, the cost of creating bugs becomes less than the bonus for that bug. The age of the bug would be a weight, since the age of a bug corresponds roughly to it's difficulty and importance.
Admin
Well duhh. I once ran into a scheme that actually worked. The project had a bucket of money available (say 20k). When testers found defects they got a premium for each defect found. Once the project was over, whatever remained in the bucket went to the developers.
Admin
At work we have a 'beer fund' that you are expected to contribute to if you break the build -- IF you check something in that causes other people to have to fix your bugs to work. Then, we name our releases after beers, and use the fund money to drink our release after we push.
Admin
"It would work better of the programmer had to pay the tester $10 for each bug the tester found and the tester had to pay the company $100 for each bug that made it into production..."
You'd think so, but you'd be wrong. First your programmers would quit, then your testers. From an economic perspective this seems almost exactly the same (so long as you moderately increased everybody's base pay), but from a psychological perspective, it's not.
The "market open" idea isn't too bad, but still provides an incentive to create obscure bugs and pay attention to be the first to catch them
Admin
I read this once in a Dilbert cartoon. The Pointy haired boss declared a $10 bonus for every bug fixed... and there was much rejoicing.
Admin
You're mistaken, that IS the WTF here. It made me go WTF, at least.
Admin
If you just restructured it by giving everybody a "bonus" that got lower and lower as more bugs happened, it would go over with flying colors. Only problem there is that the guy who really really sucks would be capped at whatever the amount of the "bonus" was.
Admin
As a reduction off a fixed bonus per person. I'd hate to see anyone lose their salary.
Admin
It's be interesting to see what happened if the $10 the testers got came directly form the developer's salary... ;-)
Admin
As Wally (from Dilbert) remarked a few years ago - "I'm gonna write me a new minivan!"
Admin
Cheating stimulates creativity!
Admin
It's pretty obvious how many people aren't reading the comments before posting. (I hope no one has said this already.)
Admin
Admin
No, Damon was right. The idea (and professional ethic) is to make code better. Making the code worse so that you can catch it and profit was wrong.
I don't subscribe to the "damn fool" theory. If a man leaves his wallet on the driver's seat of his car and leaves the window down when he walks away he may be a damned fool, but the guy who takes the wallet is still a thief.
I don't buy the whole "they had it coming" defense, either. Crooks have been soothing their consciences by blaming the victims since at least P.T. Barnum, but tradition isn't morality.
The ethical choice is to choose to be neither a damned fool nor a thief.
The WTF is that this has been a known scam since way back in Dilbert's "code me a minivan" comic, years ago.
Admin
WTF? I'd be right in there, writing the bug market trading software and web site.
Admin
I'm sorry but the real WTF is that all employees (including the CTO who organized this hairbrained scheme) are still employed. This is no way to conduct as professionals, and somebody should have told this CTO that the plan needed to be rethought. I know that the American culture is one of saying yes to the one in control and not of telling the truth (and there are plenty examples of that throughout that 'wonderful' country) but this takes the biscuit. I know this sounds very naive and there will be people telling me to grow up, but really, how can those developers and testers look themselves in the eyes and say - without bursting into tears - that they are professionals? How can that CTO look into the mirror without seeing the reflection of some kind of baboon-faced creature not capable of thinking a plan through? How does that company survive with such nincompoops in control?
The only person close to a professional is the developer written about, and the only fault I can detect in him is that he gave in to fraud just for a measly fistful of dollars. I am not a socialist or communist, but this is what true capitalism will lead to: dumb leaders, fraudulent employees and profiteers, leaches, a true Dilbert culture..
Admin
Yes, I also heard the story before. Several times. In other companies. In other industry. Hell, even outside of any industry...
Admin
Honestly, this uhm.. discussion shows what is wrong in the software dev world. Half the fucking people in the business have no pride in their work. And people wonder why programs and OSes wont work properly? Gee, I'd say its a wonder they work at all.
Admin
Doesn't work. First, nobody will accept working on difficult parts of the code. Second, the QA department will never sign-off the release.
Been here, done that. A better incentive program is:
Developers: Give them a bonus if the product ships in time to beta customers + additional bonus if beta customers are happy. QA: Same as dev, but have a bigger proportion on the "happiness" of beta customers. Happiness is defined by "goes into production" Support: Base the bonus of customer satisfaction. How you measure that depends on the kind of product you build. Product Management: Bonus for first beta customer. Bonus for each customer during a certain period.
Of course you need proper management to prevent people from "gaming the system". In particular hard metrics are generally a bad idea, because it goes into endless bickering (say if you define "customer is happy" by the number of support tickets, people will cram several issues in a single ticket), and create terrible mood. I have seen stupid management try to put the bonuses of both dev and QA under the condition of "ships with no critical bugs + have less than 5 major issues". Wtf. Of course, with soft metrics you get the issue of management not issuing the bonus for spurious reasons. That is why part of the management bonus should be based on the bonus of his team.
The worst of all occurs when management itself start gaming the system (for instance, if their own bonuses depend on how small the bonus for their people are -- don't laugh, I have seen that).
I have witness a case where the bonus was based on an percentage of a sale, which occurred but was much bigger than expected (a little above 10 million of euros), because the contract was for a worldwide installation. The manager instantly fired the employee responsible for that sale, and claimed the bonus for himself, because the policy was to allocate the bonus for the department at the moment of the sale, but give it to the employee only if he was in the company at the end of calendar year...
Admin
Someone's been reading their Dilbert books again....
Admin
There's a couple of problems with all the alternative solutions I've seen so far...
dev pays tester $10 per bug found (possibly subtracted from a bonus, not from base salary): Postitive reinforcement for tester (good), but negative reinforcement for dev (as someone else mentioned, much less effective). I suspect devs will start doing the testers job, rather than their OWN job (developing). Better code, but since devs are spending time testing rather than coding, everything takes much longer. Also creates friction between dev/testing.
dev AND tester pay company for every bug found (during testing or after testing, resp): Negative reinforcement to both (see above). Net result is testing goes up by 1.21 jiggawatts, new code slows to a trickle (for fear of introducing new bugs) and everything grinds to a halt. At least dev and testing aren't competing.
devs/testers split a pot of cash... division of cash based on bugs found and devs get the leftovers: Again, a complete focus on fixing bugs and not checking in new code unless it's flawless (for fear of losing your slice). We're back to dev and testing fighting each other though.
The essential problem is that you can't reward devs and testers on the same metric. Devs aren't supposed to do the tester's job, they're supposed to develop! Therefore, the system has to reward them for developing (perhaps penalize them for unfixed bugs, with the penalty small but increasing over time). Rewarding testers for finding and reporting bugs still sounds good to me.
Therefore, I present my solution: Testers split a pot amongst themselves for bug-finding. Perhaps the pot shrinks over time if there is outstanding 'untested' code waiting for a tester, or if code isn't completely tested (that is, you ran only 1/2 the test cases... only counts as 1/2 done).
Devs split a pot for requirements-completion, and the pot size is slowly reduced over time when there are outstanding bugs. Requirements would need to be sufficiently detailed, but don't we want that ANYWAY? Devs have to have SOMETHING to work from, so there should always be something that you could put a tick box next to when it's completed.
Structure the pot sizes and decay rates/delays as you see fit.
How's that?
Admin
The real problem here is that they got what they asked for. Unfortunatly they didn't ask for what they actually wanted. They are paying per bug found and that is exactly what they got, when in fact what they really wanted was to pay a bonus for improved quality. It's just that that's hard to measure so they chose to measure something easy (and wrong) and reward that instead.
They did the same thing where I work. Our objective payments depend on the absolute number of bugs in code sent to QA being less than some predetermined numbers over a period of time. We can meet that by not shipping any code to QA! in fact if we finish code early we are given a direct financial incentive to delay shipping it to QA because it will mean the number of bugs found goes up.
Another example where the idea was good, but it's hard to measure the figure they actually wanted to so they measure something easy and similar sounding and reward that instead. And then wonder why it's made things worse, not better.
Admin
The compensation scheme reminds me of one I benefitted from. We had a big project to do and people were already exhausted from working long hours. The CEO of the company announced at a general staff meeting that all hours over the basic seven per day would be paid at double time! The only problem was our company operated flexi-time already. It took us about five minutes to work out we could work four hours one day, ten hours the next (ad infinitum) and essentially get an immeadiate 20% payrise for no extra effort. The "incentive" scheme carried on for months before the rules were changed.
Admin
That's... amazing. It's the first one I've heard that actually works.
I read about a similar program in 'the way of the weasel', which is basically a book written by the author of Dilbert on how to be a weasel. It contains "tales from the trenches", ie actual letters sent by fans which on some occasions evolve into strips. The really funny ones are the ones he comments in the spirit of "I'd make a strip about this, but no one would believe it could actually happen."
Anyhoo, the Dilbert strip above is indeed based on a real-life occurrance. Sadly, that one ran for months before management noticed a few developers pulling thousands of dollars extra per month and pulled the program.
//captcha: nobis, dona nobis mucho $$ anyone? ;)
Admin
Personally, I would not whistle-blow on something small-scale as this, but I'd prefer not be involved. While this particular example doesn't appear to me as dramatic as some here have suggested, I would have a great deal more respect for the cheater crowd if they could at least honestly admit to themselves that what they are doing is wrong.
This "but the other kid did it first!" style of justification is pathetic, really.
I wouldn't call it a gesture of goodwill either. Companies exist to make money, which however doesn't necessarily equate "screwing someone over". But it doesn't matter anyway, because they are they and you are you. Separate issues.Here's some food for thought: I have noticed that the stereotype of the cheap outsourced Indian "can i have the codes pls"-programmer is a frequent topic of debate around here. Some people seem to think that even considering a topic like that would be racist and therefore it cannot be grounded in reality. Well I happen to think there's a lot of truth to this stereotype, but it's got nothing to do with race.
I think there's indeed a cultural problem here. But it's fixable. I think it's simply a lack of proper working ethics. Not so much the Calvinist sense of the word (after all they do work hard and long physically!) -- but there appears to me a lack of pride in one's handiwork that's unfathomable to me. I'm not morally superior or anything -- I'm simply not wired like that. It may be simply archaic pride on my part, but I'd claim that pride can be beneficial for the reason we're seeing here.
If you like the perspective of doing mindless grunt work 80 hours a week for a lousy salary, just go on. There's a whole lot of Indians out there, and many of them aren't going to pursue mediocrity forever.
Sorry for the lecture; needed to vent a little. Please take it lightly. slowly backs off
Admin
Speaking of bonuses, when I started my first job the bonus scheme used different metrics in each department (devs based on something like code reviews and delivery on time, sales based on sales etc), and there was a company-wide portion, department portion and individual portion. Except that it was all-or-nothing for each portion, and became expected, it did work well. Then it changed - so there was only the company portion, and it was based entirely on sales. Oh yeah, did I mention that the product was developed and sold in completely different continents? Devs had no direct influence over sales, but their bonus was based entirely on that...
Admin
negative reinforcement is when something bad stops when you do something, e.g. your mum stops nagging you once you've taken the bins out, or your boss stops nagging about a bug fix once you fix the bug.
Punishment is when something bad happens because of something else. eg. you are charged money by your manager when testers find a bug in your code. This, of course will only stop the behaviour (producing bugs), not direct the behaviour. So the likely out come is that instead of starting to produce bug free code the programmer will quit (path of least resistance).
You could fine a programmer £1 for every day that they haven't fixed a bug (an example of negative reinforcement), and the likely outcome is that the programmer would leave, so it's no better an outcome than punishment in that sense.
Anyway, just a minor semantic rant.
Admin