How should software developers be paid?

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 …

[Anonymously Deflowered]

I don't see an answer to the problem

As the article has already pointed out, there is a flaw to every argument; where there is a financial advantage, people will strive to cheat the system! I refer readers to this excellent tale of a black defect market that formed in one company when employees were told "For every bug found by a tester and fixed by a programmer, both would get $10."

http://thedailywtf.com/Articles/The-Defect-Black-Market.aspx

I think the only answer is to have regular peer reviews, coding standards checking by a lead developer, and the quality of work to be taken into account at performance reviews.

[Anonymous Coward]

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.

[Anonymous Cowherd]

<title>

B

y

t

h

e

l

i

n

e

will do just fine. Thanks.

[Gulfie]

Its not JUST about bonuses

I've worked for several large organisations over a 20 year career in software development and with exceptions in the smaller consultancies, nobody pays bonuses (or indeed overtime) any more. Thinking back, I've not held a job that paid overtime for over ten years. And I've only once worked on a project where a bonus was paid (and wrongly so in my view although that didn't stop us taking it).

I think bonuses could help deliver better productivity and build a tighter team. As a team leader you always know who is the weakest/laziest/best developer in your team and you juggle the work appropriately. A bonus for meeting delivery criteria (for example, a deadline with no more than 'x' defects) is just the sort of thing that helps build teams and galvanise the lazy and weaker members to try harder. I would propose two levels of bonus, one at the individual team level for meeting delivery criteria, and one at project level for overall success, so that if a team misses out on its bonus it still has motivation to contribute to the overall success of the project.

Unfortunately the larger companies frequently try very hard to make it difficult for projects to be successful, the two biggest problems being management flexibility over the customer's requirements and an inability to ensure that information needed from the customer is available in a timely fashion.

IMHO there are five key areas to a successful project, and failing to address any one puts a project in jeopardy:

- Bid a sensible price. If the business can't be won at a price that makes money, walk away.

- Ensure the contract contains a clear set of requirements. Do not sign up at a fixed price if it is unclear what is to be delivered.

- Build a balanced team, train where appropriate and motivate them to achieve realistic delivery timescales.

- Give the team appropriate tools for the job in hand.

- Keep tight control of scope and don't capitulate to customer pressure to both make scope changes and stick to original timescales and/or price.

[Anonymous Coward]

specification

Often far too much is left to the developer. Stuff like specification documents are often left to the developer to write despite them not being best placed to do this. As a contractor i cannot remember the number of times i have been given the proposal document that marketing used to win the contract rather than any decent list of what the software should be.

Only yesterday i sent a spec document back to the business owner to check i had included everything. Only one additional requirement was added

"Produce reports and data extractions based on selection of any set of

criteria or contents" ... the any and all option as i lovingly know it.

This whole discussion is mis-focused, as often a developer is hired where a designer, project manager, account manager, architect, tester and administrator would be best.

To be honest i would rather stick to my daily rate for contracting, as i do not believe there is any fair way to measure a developer's work unless it is being done by another developer... certainly not by management or other non-tech people.

[Anonymous Coward]

I want to be paid by weight.

In chunky KitKats.

[Anonymous Coward]

@AC

"In chunky KitKats."

Genius.

[Adrian Jackson]

How should software developers be paid?

Generously.

Mine's the threadbare one...

[Jax]

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).

[Saul Marchant]

How should developers be paid?

In Rupees, apparently.

[Andrew Miller]

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

[Anonymous Coward]

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?

[Anonymous Coward]

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.

[Britt Johnston]

by the hour

..not that you whip up people to working at top speed all the time, but it does provide an incentive to project managers to keep the runway clear.

@ gulfie:

on bonuses, our internal developers do get overtime as time off, and when the going gets tough (when the boss approves) they can choose between cash and time.

on project costing - agreed that risks taken on the project shouldn't be passed on unfiltered to the developer - unless he is a one-man-band, taking on both. Often such hybrid guys are worth hiring, they are good at optimising effort and results.

[Anonymous Coward]

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?

[Anonymous Coward]

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.

[Anonymous Coward]

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!

[Anonymous Coward]

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.

[Nic Brough]

@RotaCyclic

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

I wouldn't bet on that either - with the Inland Revenue going after contractors under IR35 (it effectively turns them into permys, but without the benefits like sick pay, holiday pay, p/maternity pay, redundancy payouts, job security, share/health/pension schemes and so on), and investment banks cutting costs or imploding...

Anyway, paying developers by performance would be nice, but it's incredibly difficult to actually measure - as noted above, most of the reward schemes are wide open to abuse. Number of lines? Padding. Bugs found/fixed? Collusion between dev&test.

Maybe "user satisfaction" needs to be taken into account, but it's not often we see a user say "thanks" when things go well, they usually remain quiet until things go wrong.

[Anonymous Coward]

(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.

[Dave Long]

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.

[Anonymous Coward]

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.

[J-Wick]

@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...

[GreyCells]

Paid by the line? Hmmm...

...that'll be jQuery developers well and truly stuffed then.

[Solomon Grundy]

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.

[Anonymous Coward]

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.

[Kurt Guntheroth]

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.

[ratfox]

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...

[Anonymous Coward]

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.

[Solomon Grundy]

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.

[Rich]

1980's print industry styleee

Basically what we need is a really strong union and a range of restrictive practices. Like only a BA is allowed to touch requirements, but isn't allowed to have involvement in the design, the architect musn't write a line of code, the tester isn't allowed to touch the spec, etc.

Or it's down tools, all out.

Then we can all work spurious double shifts, sign on for two jobs as "Mickey Mouse" and "Donald Duck" and generally screw the employer for as many dollars as possible.

I'm on to be "Father of the Chapel".

[Ishkandar]

@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) !!

[Anonymous Coward]

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.

[Anonymous Coward]

To the fellow that said "well done" is enough

No, it's not. Software developers are getting shafted with their salaries left and right. We often develop software that nets millions in revenue - we bloody well deserve to see some of that money! We wrote the damned thing!

I'm not interested in hearing "good job" because I don't care what some git of a project manager thinks of my software - I'm far more qualified to evaluate whether I've done a good job than he is. And if a good job done, then I want recompense for it by seeing an appropriate slice of the money it generates.

[jake]

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.

[Anonymously Deflowered]

^ Good point

A well-timed "well done" or "thank you" does actually go a long way and it doesn't cost anything.

[Astarte]

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.

[Anonymous Coward]

You want it when

I like the point about about builders and standardised construction techniques. The big problem is identifying which bricks to use. I'd draw a closer analogy of stone masons building a cathedral.

"Right your emminence 1 cathedral size 7 no problem, Oh you want gothic and Norman arches, Gargoyles on the west and Cherubs on the North, Spires and Tower.. "

30 years later

"Bell tower Nobody mentioned a bell tower'' .

20 years later.

"Multi-demonitional with his n hers cloisters Oh for F..."

Software is a craft skill, some parts are highly creative and time consuming, other parts are technical, laborious and predictive. How would you pay a jeweller, ceramicist, musician ?

BTW How to annoy a business analyst. When they ask how long to build it, based on their conversations with the customer, ask them how many words will be in their spec .. When they splutter "I don't know yet I haven't written it..." Just Grin..

[Paul Berry]

Do not reward on lines of code or bugs found

Or you'll deserve everything you get: stretched-out code with lots of linebreaks and hundreds of trivial bugs.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[Kendal]

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!