How should software developers be paid?
By the line?
Customer Success Testimonial: Recovery is Everything
Reg Reader Workshop The success of any software development organisation depends on balancing a whole range of factors from the skill sets through tool sets to the way in which everything is managed. Over the past few weeks, you had your say on a lot of this stuff in the reader workshop we've been running.
One of the sentiments that has emerged is the view that there needs to be a bit of give and take between those running the show and individual developers. No developer wants to work in a completely locked down environment in which they have little freedom to optimise they way they work and exercise a little creativity. On the other hand, the general consensus is that there needs to be some consistency in terms of process, approach, standards and tooling, otherwise collaborative team working is undermined, productivity suffers, and what's ultimately delivered is more difficult and expensive to maintain.
One way of achieving balance is to define policies and procedures laying out the way things should be done, making it clear where developers are allowed some freedom and where they are expected to toe the line. But the challenge is that you can never be exhaustive in terms of the rules you lay down, and developers will always find ways of working around constraints that they cannot see the point of or simply don't like. Then what do you do - discipline them or dock their pay?
While threatening to beat people with the metaphorical stick if they don't comply might work in some circumstances, encouraging the desired behaviour in other professions tends to be achieved through the offering of rewards for results achieved. The most obvious here is the paying of commission to salespeople or bonuses to managers who meet the business objectives they have been charged with achieving.
Common though it is, however, this kind of approach doesn’t always work. The recently highlighted disparity between performance bonuses paid by banks to senior executives in the months, sometimes weeks, immediately prior to the business imploding is perhaps the most prominent example of ineffective reward systems currently. On a more mundane level, most of us at one time or another have probably been a victim of call centre agents who are clearly targeted on the number of cases closed, rather than problems solved or customers satisfied. The point is that reward systems only work if they are based on the right measures.
Coming back to software development, it is interesting to consider whether remunerating developers on behaviour or results might be a way of encouraging that all important balance and driving overall performance of teams and projects. But if you go down this route, what would bonuses or other reward schemes be based on? Raw productivity measures such as lines of code cut or time to produce a deliverable are dangerous unless quality is taken into account. Then what about the guy who sits there thinking or experimenting for ages without actually producing anything, then suddenly produces one of the most creative, elegant or efficient solutions to a problem that exceeds all expectations?
We would be really interested in your views and experiences in this area. Does your organisation pay developers bonuses? If so, what are they based on and do they work at an individual, team, department or overall company level? More importantly, do you think the scheme is effective? And if developers in your organisation simply receive a flat salary at the moment, what are your views on if and how a developer reward scheme might be applicable?
Please add your comments below, and if you have any thoughts on the higher level question of how development teams should be managed in general, you might also want to contribute to our latest poll running over here. ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
Pay programmers by the line -- absurd!
Pay programmers by the line -- absurd! Some code is a no-brainer, while other code requires considerable contemplation. One file can be knocked out in an hour, while another takes a quarter year. As a programming veteran I aspire to elegant and efficient code. In an industry where there is an infinite way to program a task, I shiver at the thought of what verbose crap will be spewed from the minions of opportunists engaged in computer programming. Just consider the maintenance costs of such code thereafter. Whoever the h*ll first proposed this does not belong in the tech trade, but the rag trade!
But...
Any job that I've ever worked in, the money I get paid has always been part of the up-front negotiation that takes place. If a company is unable to renumerate me with what I require, I find another company that is. This seems quite a simple concept, so unless you've actually had a salary decrease or are working under some kind of feudal conditions, you can't really complain because, well ... you presumably signed on a dotted line at some point agreeing to the money you receive??
And actual good developers are worth every cent of their pay and usually get paid their weight in gold (hint: if they're not they'll move on quicker than you can say "underpaid"). In my experience, around 4/5 of developers are glorified amateurs though who don't understand the concept of not copying and pasting, don't understand datastructures (and using the most appropriate one for a given situation) and couldn't tell a strategy from a template pattern (and much more importantly, when to use either) if it came up and slapped them across the face. Witness the guy complaining that his boss had the temerity to ask if a web/database (gee, there's a complicated system type) solution could be provided by Excel. A professional would be able to assess the pros and cons of either method and then effectively communicate that to his manager (there's more than one way to skin a cat).
Anybody not happy about their pay or working conditions should simply move on and find a place to work where they're happy. Either that or they're not good / assertive enough to do so, which probably explains the conditions they find themselves in the first place.
bonuses and metrics
Where I work developers get bonuses, pretty nice ones at that, but I believe this is fairly unusual. In my previous dev jobs there were none at all.
The company measures general productivity using a set of metrics based on your own assessment of your productivity, initiative, creativity, quality, test coverage, problem solving track record and so on. This is then balanced against the opinion of your manager and to some extent, peers.
But really all it boils down to is whether or not you're really "getting stuff done", are you really "putting in quality hours", "solving more problems than you're creating", and so on. To any manager with real dev experience, this will be fairly obvious. But it has the potential to break down where the manager is not paying real attention, or hasn't the skill or experience to have an idea of how truly good or bad the team members are.

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring