How should software developers be paid?

Battery monkeys

Hmm. They shouldn't be locked down?

Imagine if the construction world worked like this.

Builders standing bricks on end or using mortar made from jam, just because it allows you some 'creative freedom'

Once everything becomes as standardised and nuts and bolts and bricks, then you will realise that you are just little battery chickens.

I want to be paid by weight.

In chunky KitKats.

Is it worth suggesting....

unexpected bonuses?

If they're predictable they can be gamed. So make them unpredictable and not tied to any particular action but just as a summary of line managers opinions. (shuold they get this bonus, they're due some goodness, do they deserve it).

How should developers be paid?

In Rupees, apparently.

Joel Spolsky

Joel Spolsky recently wrote an interesting article where he argues that incentive plans based on measuring performance always backfire:

http://www.inc.com/magazine/20081001/how-hard-could-it-be-sins-of-commissions.html?partner=fogcreek

How should software developers be paid?

Here's a radical idea. Developers should get paid similar perks for fulfilling the sale as the salesman gets for making the sale in the first place. Obviously this depends on conditions of sales, timescales and so on. Probably suited to more bespoke or variant solutions. But even so, If you as the developer put a lot of effort into supporting a sale with modifications, integration, support, etc. why not get a slice of the final cake?

Bugs vs lines of code + deadlines met

I think a pretty good reward system that actually encourages quality is amount of bugs per lines of code. Of course some bugs always slip through the cracks but QA should catch most of them. If you are churning out a bug for every 30 lines of code and the guy next to you has a bug every 20 lines, then factor in whether or not you are meeting deadlines and there you go. This will encourage developers to heavily unit test their code and at the same time keep focused on the overall project.

Harder though, is to gauge rewards for those who are "architects" of projects, and may not be required to touch very much code but still like to get their hands dirty...those that reside in the gray area between development and management.

by the line comments...

If you pay by the line, or as a ratio of lines of code to bugs all this does is serve as an insentive to make your code inefficient and rambling. After all, why would you use one command when three would do?

bonuses

I've worked in IT and software development for the last 17 years.

Hardly any of the companies I have worked for pays bonuses, and those that have, I'll be honest about this, the bonuses range from £500 to £800 per year. What a joke!

I've worked for large multinational companies and I've worked for the smaller UK based company with 40 or so employees.

The pay, generally for developers, IT people is terrible, considering we're graduates and highly capable people.

Would I recommend to my children to go into IT? Not a chance, it pays too badly.

pay

We should be paid reasonably. What do I mean by that?

I will illustrate by example.

My current employer is a consultancy, we consultants go out and do work for people, we use our technical expertise to bring in revenue. So why is it then, that the managers of our company are paid £70K and don't know jack s**t about technical issues and the consultants that are actually doing the important work, without which our company simply could not survive - we're a knowledge based company, and we are in effect selling the skills, the knowledge of the consultants - we consultants are paid half the pay of the managers!

So let's have some reasonable pay, and let's kill this f***ng idea, that "I'm a manager, I'm responsible for people so therefore I deserve to be paid a lot more than the real guys doing the actual useful work, without which our company would not exist".

We're the guys working until late into the evenings to deliver the project work on time, the managers aren't!

The way to earn the most money

If you want to earn good money in IT there are only two ways to do it: Contracting and Investment banking.

Being a permy in IT is pathetic, unless you happen to get really lucky.

(untitled)

I think software should be treated equally the same as, say, music. If a songwriter develops a song until it is fit for purpose then isn't it so that they get paid healthy wads of cash, and again every time it is used ? And retire to their multi million pound villa by the age of twenty ? So how come it's different for software? I want my slice of the cake too. Fair's fair.

Do you really want to repeat yourself?

I'm not sure that giving bonuses to developers for the number of lines of code they write is a good idea, it encourages developers to break the DRY principal which makes code hard to maintain but not necessarily bugridden. Meeting deadlines ( based on a certain number of 'points' for important tasks to be completed for a release ) and writing good code ( low number of bugs and good performance ) would be a better indicator as to how your team has performed during a period of time and reward those who have worked hard towards a project.

This would of course be judged by an experienced team leader / manager who would have to know their way around code ( and the business ) to a certain degree.

On retainer

A few hundred years ago in China you would set up a retainer with a doctor making monthly payments. When you or your family members became ill the money would stop. It was an incentive for preventative medicine and for a fast and efficient cure. Maybe try that with developers. Provide them with a retainer while the system is up. When bugs are discovered or there are system problems you stop paying them. Incentive to develop good, stable applications that are easy to support.

On the control issue, you just need to define the boundaries and ensure your controls - people, process & technology - are effective. Anything within that agreed perimeter is fair game, anything outside the agreed perimeter is defined and controlled.

@RotaCyclic

I would have to agree. An even better way is to move out of IT altogether, unfortunately. IT will never, *ever* be paid more (on average) than sales or management - unless you're in a really forward-thinking company. Too many bosses (who control the purse strings) are of the opinion "I could do this in Excel, why do I need a database and website?" (no, it was a serious question that a boss once asked me) - they don't understand it, therefore it must be easy.

The situation you describe happens in countless firms - only way to buck the trend is to become someone on the "business" side, with a good understanding of the technology, rather than someone on the "technology" side with a good understanding of the business.

The business side is always where the money is...

Construction Work and Construction Pay

Unless you're managing a development team, designing architecture, or dealing face-to-face with the customer(s) - developers are waaaaaay overpaid. What they are doing is no more special than the construction yard worker that is cutting 2x4'sor pushing a wheelbarrow. Not very special and with a little training, anyone can do it. It all comes down to good specs and good management (as results from the other "Agile" surveys can attest).

We've got about 30 developers here and they all work on my "penalized flat salary" system. In this system your salary is built around the assumption that the developer will create code that is 100% error free. In final pre-release testing any "bugs" found are tracked back to their creator who is penalized depending on the severity of the flaw. Developers are peanalized for bugs in their code up to one year after deployment. Penalties are monetary in nature and are taken directly from the developers paychecks. (i.e if you release a bug then your paycheck is reduced by 5% or something, depending on the severity and several other factors)

We pay exceptionally good salaries and give lots of other cool bonuses and such but we demand quality. No whining, no excuses. If you mess it up you won't get paid. We've had several developers quit because they didn't get paid for a few weeks but that's their fault - which is what makes the system so great. The developers are responsible for their own success.

Methinks I'll be giving _them_ money

In the last couple of months certainly I've written a 'negative' amount of code. I've encountered a lot of particularly grungy code that when refactored ended up dramatically shorter than it had been, even after whatever changes that were needed had been made. How do you measure refactoring? If you have say 1000 lines and afterwards it is 650, and much simpler to understand to boot, few would doubt you've done a valuable job. But that 650 lines wasn't stuff you've written - it may only represent the same effort as say 150 lines of code.

Then there is the question of what the code does. High level glue goes together very quickly and is often the major part of an app on a line count basis. The low level data structures take much more effort - sometimes 10 times as much on a line per line basis.

Ultimately, quantitative measures are never going to accurately reflect effort and value. The only way of truly reflecting performance is code reviews and annual appraisals - the is no subtitute for human judgement.

it's management, stupid

So, engineers who don't like their job and think they're smarter than their manager think they should be paid by the line, or any other semi-objective but manipulable measure of what they think they do best. Right?

It is management's job to gather together a team that works harmoniously; to work with the team to establish procedures and standards, and, if there is a developer who can't be comfortable working with the team, to make the hard decision and encourage that developer to explore the wider space of opportunities at other companies.

It is also management's responsibility to assess the performance and capability of each member of the team and compensate them in proportion to their contribution. It would be great if there was a single measure of performance, but that's a pipe dream. Design engineers are not milling machines. They do not stand alone. They do not produce at a steady rate three shifts a day. (If they did, software would always be delivered on time and on budget). Devs are imperfect machines; each one unique, with skills and deficits. Live with it.

And it's the individual contributor's job to move on if they aren't happy, rather than trying to impose their style on the whole team, or demand that there be no shared style. Managers are imperfect machines too. They focus obsessively on social aspects of developers interface with each other and management, and ignore devs' terrific skills at template metaprogramming or protocol analysis or whatever. Which is what they should do.

What developers are paid...

Very simply, they are paid as little as it takes to find somebody competent... Like all employees the world over.

"to make the hard decision and encourage that developer to explore the wider space of opportunities at other companies"

Wow, nice sentence. I prefer "give him the boot", though, it's shorter...

As much as they can get :)

Really it should be linked to functionality, hourly rate, and a cut of the action.

Functionality you reduce to simple sentences, a good dev can do about 8 (1 an hour) functionalities a day, a bad one might struggle to do 1, the average is 4 ( 3 - 5 ).

You want the 8s you don't want the 1s, so you pay the 8s ten times what you would have paid the 1s and about twice the 4s. You never hire and keep 1s, you keep the 4s, and the 8s own the project.

Hourly rate is based on what they bring to the party; knowledge of different languages, project tools, and problem spaces.

The cut of the action is a little harder but you are looking for about 10% in a medium sized project, 5% in a large, 50 - 100% in small, the % taken will probably play with the hourly rate either up or down.

If you cannot work out the action, then you shouldn't do the project, the only projects you should do are ones that increase profitability.

Consultation charge at a fixed rate per hour. In that time you negotiate the functionality required.

I have seen things like email server popped in as one functionality point, the client expects something all singing all dancing, and the developer configures sendmail, so that would be a point of negotiation. There about 16 functionality points to an average mail system set up, can go as high as 50 odd.

That is the way to do it, clients like it, management doesn't.

What management wants to do is pay a low hourly figure, harass the developer, lie about the functionality, introduce scope creep at the end, and not pay overtime. They will hide behind team building, and veiled threats of if you don't like it then leave, which actually is what the managers should be doing themselves, namely ejecting from the process.

Another Thought

Paid "by the line" sounds OK for some twits but they really aren't thinking that through. What defines a "line"? How do you report on it and how do you establish standards that everyone can work with?

It's a fabulous opportunity for someone to develop software to accomplish this and a great opportunity to create another bloody standards group, but paying "by the line" is a long _

long _

way _

from _

reality _

End Sub

Pay for revenue generating results only. To developers this means working code.

@RotaCyclic

What you have said about investment bankers are so, so true !! They are nothing more than jumped-up, glorified second-hand car salesmen !!

One way to avoid this is to get together a bunch of like-minded people and form your own consultancy/software company. It's what I did after years of busting my arse for unappreciative bosses !!

The downside is when times are hard and you have a wife, kiddies and a mortgage to feed !! However, given a choice, I would still do the same all over again !!

On another subject, there is still no reliable yardstick to measure creativity and I thought that the pay-by-lines-of-code went out with COBOL programmers (I'm old enough to know some of those personally) !!

Of course money is important

but I've always found that a few well placed " well done"'s and "great work"'s do far more than bonuses. Recognising an individual as a valuable contributor and letting them know when they do good is a much better way of keeping staff. And happy coders produce fewer bugs.

Stop.

I just realized something vaguely unsettling ...

Dale Vile of Freeform Dynamics ... Are you aware of the phrase DYOFDW?

Why should I provide you and your company my over a third of a century of computer industry experience for free? Especially seeing as you are making money from the info. That's a serious question, dude. Or dudette, depending (not an intended insult, I know he and she Dales ...).

I am available for consultation at my normal rates.

If you have to ask, you can't afford me.

Individuals?

In my experience software errors are often the result of several factors including lack of or poor interpretation or definition of requirements plus poor or inadequate interface definitions and inadequate testing. Peer approval is powerful - providing the peers are of suitable calibre. System failures are often discovered even when the individual systems pass all tests, so who gets rewarded/punished and for which components. The problems are exacerbated when multiple companies and or countries are involved.

Payment is usually well defined - peanuts for the programmers and dry roasted peanuts for the seniors.

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.

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!