Hacker News Reader

Comment by systemizer | Hacker News Reader

Self-maintained groups and incentives based on performance. It would be interesting to adopt this in the tech area: the amount and quality of your unit tests means you get paid more.

You can also do code analysis: look at branching factors; code duplication; runtime performance; etc

This might be hard to implement in a company setting; but it may be easier to apply with contracting work.

View on HN

IBM was big into quantitative code metrics in the '60s through '80s, but the practice ended up developing a bad reputation, since the metrics inevitably created perverse incentives to game the metrics themselves, and sometimes got in the way of doing the right thing if it didn't fit the rigid model's idea of the right thing.

This is basically a version of Campbell's law, from a 1976 paper by Donald T. Campbell: "The more any quantitative social indicator (or even some qualitative indicator) is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor."

Lines of code per unit time (LOC) is probably the most notorious, but there have been dozens of attempted improvements. Function point metrics were a late-'70s approach (also out of IBM) that tried to fix some of LOC's shortcomings as productivity metric, but turned out to be highly correlated to LOC and also problematic. There are dozens of books from the past 50 years with titles like "Applied Software Measurement" and "Measuring the Software Process", but they've become associated with bureaucratic bigcorp software engineering.

Or the "cobra problem". The British put a bounty on cobras in India (to reduce snake-bites). So the snake-catchers bred cobras (some of which escaped, making the problem worse).

Incentives are powerful things.

How do you quantify whether someone is solving a problem the wrong way, just because that way will score better on the metrics?

I can remember in the 90s being part of a team where Software Lines of Code (SLOC) was a monthly metric. Highest won a bottle of champagne. People actually stopped writing loops. It got a bit crazy.

I don't have a good answer for you, but let me shoot a question back at you: "How do you determine whether the code you're looking at is good or bad?" Surely, there's an algorithm you run in your head that looks at specific features of the code and analyses them. All I'm saying is that there may be a way to automate that algorithm and use it to drive incentives. Even if the algorithm is as simple as "make sure X and Y unit tests pass."

Assert.IsNull(null);

It's easy to make unit tests pass. To defeat this kind of gaming, you'd need extensive code review of the unit tests. But that circles around to your point: when you look at code there's something that tells you whether it's good or bad. That algorithm can't be based on passing tests, because tests are code too and also need review.

If you had a team of completely selfless developers, you could probably have code-reviews and peer-reviews drive incentives. But as soon as the team suspects it's a zero-sum game and they're competing for a limited prize, they're going to stab each other in the backs, and your best developer will be the prime target. That'll make your best developer leave, and the next-best becomes the target, until all you're left with are lousy developers who are only good at office politics.

I recommend reading http://www.amazon.com/Measuring-Managing-Performance-Organiz... for an analysis of how motivation systems based on measurements often become dysfunctional.

Dysfunction may arise when you are unable to measure all the relevant dimensions of the work being performed. People will often shift their effort to the dimensions that are being measured and ignore the remaining tasks, no matter how important they are. This results in less value being delivered compared to a scenario with no measurement based incentives.

The author mentions software development as an area that is specially prone to dysfunction.

Except, it's impossible to write something that can tell if code ever stops which would seem like a much simpler problem.

Just make the metric to be money and it will work. It takes a big re-org to put the tech tasks in terms of profits, but it's possible to a big extent. Break the software into ownership domains that are peer reviewed and monitored on how much money they contribute. Then sell the software in packages assembled by customers or your internal marketing and solution consultants. This way you encourage the developers to talk to the customers or marketing to collect input and requirements what needs to be done next. Developer can choose to work on something profitable or something cool and obscure, but make no money on it, it's his choice. In both cases, the developer is motivated to be efficient.

Reply on news.ycombinator.com