The postoffice horizon scandal in the UK has put the spotlight on the coding practices of Fujitsu.

With the publishing of some code snippets, several people who have looked at it have replied "Wow, are they paid by the line of code?"

Which, while often meant as a joke, has some basis in history, and it opens up the discussion, of how do you incentivise programmers and how do you judge their achievements for the basis of bonues?

It's thread time.

1/n

In the past shortly after programming went from being considered women's work, to being considered men's work (see my thread about thread, and how weaving changed from women's to men's work). Management found themselves with the problem of how to judge the performance of their programmers. You can judge a brick layers performance by the number of bricks layed, a rivet maker by the number of rivets. What's the output of a programmer? It's line's of code.

2/n

So for a short time you'd get people paid based on the number of lines of code written. Thus rather than a one line for loop such as for(i=0; i<10; i++) dosomething();, you right out do something() ten times, thus your lines of code output is higher, your pay higher. Everyone's happy. Right?

Ye gods no, you end up with write once code that's a fucking nightmare to debug.

Fortunately such practices didn't last very long. Generally.

But the problem remains. How do you judge performance?

3/n

With the modern age of version control systems and the like, we see managers using things like number of commits to git. Or new features added. Etc...

Which on the face of it sounds great. Except you encourage people with your bonus structure to write more, to add to the code base. This doesn't make for the best quality of code base.

To quote the bankers after 2008. "The incentives were wrong".

4/n

With these metrics, you discourage the sort of user who spends 3 weeks fixing a bug that's been in the code base for 3 years. In the end they removed one line, to fix the bug. By the metrics: -1 line. 1 Commit. Clearly they aren't doing as well as the person who added 1000 new lines of code... across 15 commits.

I have genuinely spent 3 days on one bug, and fixed it by removing one character.

Deleting code is often one of the best things a programmer can do.

But it's disincentivised.

5/n

In the modern age of agile with sprints and stories etc... it's easy to setup a bonus structure of complete x stories, finish x sprints, do x commits. But to do so is Just Bad Practice™.

I'd like to say I'm able to give you an easy system for how to incentivise your programmers, how to make sure they have a bonus to work towards. But there's no easy solution here.

Personally I dislike bonus structures and incentives that are solely based on my performance. I work as part of a team.

6/n