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?
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.
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?
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".
@quixoticgeek As someone currently involved in systems analysis (processes rather than code), I call that incentive perversion. Like a requirement to sign off something within X number of days drives people to sign it off before it has been adequately resolved. Happens everywhere, like sticking a cone on a pothole and closing off the report because people won't drive into it now, right?
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.
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.
The bonuses should be based on the whole team. Or ideally, the whole company. This allows you to concentrate on the quality of the product you produce, not simply hitting numbers for actions taken in the code base. We've seen disasters of projects where the programmers are burning themselves out in crunch before a release date that was always unrealistic. All that guarantees is a bug fix release a few weeks later. Late is better than buggy in most cases.
There's a lot of problems in the software industry. From poor working conditions, to poor software development practices. But most of them stem from poor management. Pushing the wrong incentives, pushing the wrong goals. This is how we end up with a simple mobile app that's 300 meg to install. Or a code base with 4000 dependencies noone fully understands.
So if you manage a group of programmers. Stop. Step back.
Step back and have a think about what you are doing to make sure that what you produce is the best quality it can be. Often this will mean freezing new features. Letting your staff fix those bugs that they've wanted to fix for years, but not been able to. Stop chasing metrics on commits and features added. You'll make a better quality product, and your customers will be happier. But more importantly so will your staff.
@quixoticgeek very much so. These things often originate after a change of management where they don’t know what’s going on, and pick up these recycled ideas from passing mgmt consultants.
Any metric with an silently gameable feedback is bad.
@quixoticgeek Decided to add this becomes an institutionally bad idea when this sort of fraud takes so long to uncover that all the main beneficiaries have moved on (leaving one or two minor peripherals as the only available scapegoats)
Burnout is a major problem in the IT industry, not just in software development. Insane on call rotas, poor management practices. They are incredibly widespread. Even in the poster child MAAAD companies. Especially at MAAAD.
You've all seen the joke. "What's the difference between a programmer and a lightbulb? The lightbulb stops working when it's burntout". But it cuts really really deep. I see so many people in this industry who are almost destroyed by burnout.
I have the big fear that in the case of Fujitsu, and the post office horizon program. The people who are going to be up against the wall. Maybe even see the inside of a prison cell. Won't be the management, or prosecutors. It's gonna be some poor programmer, who was at the start of her career. Who was just trying to keep their job by meeting the ridiculous goals set by their poor management. They won't be able to hide behind "just following orders" cos they will be too inexperienced to...
... have kept the evidence necessary to cover their arse. The same way that in the volkswagen emissions scandel. The only person who saw a prison cell in the whole VW fuckup, which increased pollution and harmed us all. Is one engineer. Noone in management. Noone who set the goals for the project. And I fear it will be the same for Fujitsu.
And all of it. From the top, to the bottom of the program comes down to one simple problem.
@quixoticgeek I cant prove this, but the inhumane treatment of engineers is a feature not a bug in the computer games industry. Burnout as a technique to deter worker negotiation power.
Elsewhere, especially in tech, the labor market has been tight for a most of the last two decades has at least provided incentives to retain.
With the mass layoffs as the investor subsidized and low interest rate fueled ride comes to a halt, retention may be deprioritized.
@quixoticgeek I just plain won't work anywhere where I have to be given bonuses to get what I think I'm worth. I prefer to be paid well, not get bonuses, and if the boss thinks I'm not performing well enough he can fire me.
@quixoticgeek
I used to work at a place with a profit-sharing bonus. It was honestly run, AFAIK, and everyone had reason to help everyone else succeed.
New upper management came in and decided that program “rewarded freeloaders.” They replaced it with a competitive bonus system.
If my pay depends on “performing better” than you, I have no financial incentive to help you do your job. I have incentive to hoard information, hog credit, shift blame, see you fail.
@caracabe Yep. I have turned round to a colleague and said "I have this list of tasks I must complete to get a bonus, I don't have time for your request, go talk to my boss and get him to swap things round"
@quixoticgeek "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away" - Antoine de Saint-Exupéry
@quixoticgeek Great thread , and very generalizable as the "lines of code/ n of commits" equivalent are rather pervasive. Ask how your doctors are incentivized for example and why they too (like everyone else) is being burned out.
@tony@quixoticgeek I have literally had middle management come in and tell us to spend the last two days before a release deadline to just randomly close as many bug reports as possible to get below the max allowed bugs for release. "The users can resend their bug reports after the release date". Any simple metric can be subverted.
@wfk@tony@quixoticgeek Isn't this why the Environment Agency has just been accused of not inspecting sites? It's always a mistake to set KPIs by factors that are not entirely within the organisation's control.
Add comment