Is it correct for management to give more importance or reward programmers who have worked on strategic and important application versus someone who has worked on a general application?
Both may have put the same efforts.

  • That is a perfect way to lose business from those who have been clients for over 10 years. There has to be a very delicate balance between sales, engineering, and other, or else competitors will take care of you.
    – Job
    Aug 3, 2011 at 15:09

9 Answers 9


First, more valuable does not always mean more difficult. For example: programming internal tools might be very useful and time saving for your personnel but the value to customers is not always visible. Pay should be rewarded on the difficulty of a project and the responsibility of a person within a team.

If you do reward teams differently there should be one condition: people should be allowed to change teams when they want to. Let those who enjoy developing the harder applications earn a bit more. Those who prefer a stress free job can do the easier applications. This way everyone is happy.

Locking people into teams where one team earns quite a bit more will lead to frustration and may leave people to leave your company.

  • +1 Absolutely agree with this comment, "Pay should be rewarded on the difficulty of a project and the responsibility of a person within a team"
    – maple_shaft
    Aug 3, 2011 at 11:04
  • 4
    Difficulty can come in the form of risk and not just complexity. Doing a dance may be more complex than walking, until you try it on a beam that is 500' off the ground. Poor developers do not get to choose to be on teams for critical applications.
    – JeffO
    Aug 3, 2011 at 11:20

It is correct for managers to deploy their developers based on maximising return on effort. Therefore, otherwise equal employees should be rewarded equally.

A manager who deploys a developer to the low value job when there's high value work to be done is grossly incompetent from a business perspective, and the developer should not be punished (or rewarded) for their manager's poor performance.

  • Still companies go out of business because of incompetent management and still even their hardest-working employees are punished by losing their job because of it. Your normative postulation sounds nice, but I don't see how you can prevent such things from happening or how you can enforce equal rewards. Even farmers doing the same work will have different earnings depending on weather and quality of their farmland.
    – Ray
    Aug 3, 2011 at 13:23

Firstly, what is meant by "correct". If the question is whether its morally defensible to pay people on a more important project more then I think so. You earn money based on the benefit you produce not based on the costs you accrue. If one programmer spends two months producing something completely useless while the other spends two days producing something which double productivity, the second one should be paid more despite having spent less effort.

From that perspective the strategic and important application is simply more valuable to the company and the employees working on that are producing more value for the company. The only natural result is that they will make more money.

On the other hand, if the question is whether its a good strategy to do so, then probably not. Automatically paying people on a more important project more is likely to introduce perverse incentives. People will try to get onto more important projects when you need them working on other projects as well. As a result, its probably better to pay people based on skill rather then on a per-project basis. As it works out, you'll probably have the highly-skilled and thus highly-paid people working on the most important projects. But you can probably avoid the problematic incentives.

  • 10
    I agree, but I have seen examples where companies put more emphasis on the "next big thing" and totally de-emphasise things like improvements to existing products, etc. In particular, they'll give bonuses and accolades after a big new product launch, but the people maintaining existing software (the software with all the customers) get all but ignored. So I would say I agree with the caveat that it's only right if the company correctly assigns "value" based on actual value, not just perceived value. Aug 3, 2011 at 8:07
  • 1
    I disagree completely. The logic assumes that peple have a choice what they work on AND that some people deliberately choose to work on something unproductive. In reality, developers can rarely choose which project they get assigned to, and if they could and valuable projects were rewarded more, the obviously valuable ones would be deluged in developers, which would not be a productive situation either. Aug 3, 2011 at 15:07
  • @Winston: Which is a horribly damaging (to the company) bean-counter logic. What's going to happen in reality is that the company becomes mired in office politics and backstabbing as everyone clamors to get into the "valuable" projects, while the highly-skilled people who don't want to play that game leave to find employment with a less dysfunctional company that rewards skill rather than politics. Aug 4, 2011 at 7:47
  • @Michael, I agree. But that seems more of an objection to the methods used to decide who is assigned to a project then to the notion that the people on the important project will be paid more. The smart company will use the extra money available for that position to attract programmers with better skills. Aug 4, 2011 at 8:07
  • 1
    @Winston: That makes a lot more sense, but assumes that each project has an independant hiring budget and makes independant hiring decisions. Which I don't think is the case anywhere. We agree that the goal of the company should be to get the most highly skilled developers for the most valuable projects to ensure they succeed. I'm saying that in an environment where hiring is centralized and developers take on projects one after another within the same company (the most common case), basing rewards explicitly on the value of the current project is not going to have the desired effect. Aug 4, 2011 at 8:18

Yes, most likely. I think the biggest reason for rewarding developers is to prevent them from wanting to move to another company.

If you have three developers who maintain a very important system and twenty developers who maintain another system, you're probably going to be more worried about keeping the three developers, since losing one of the twenty isn't such a big hit. It might make sense to spend more resources keeping the three developers happy, if you can't afford to keep them all happy.


I don't think there is such kind of justice like "equal pay for equal work performance". This is just a useful myth found in many societies. I don't know whether your question is about laws that may exist in some countries, or whether you want to raise an ethical question. Either way I would no know how to measure or to enforce equality. Is a taxi driver performing so much less than a football star whose earning might be higher by several dimensions?

Payment might depend on how good negotiations were when a programmer changed company or what the market situation was when his employment started, so I doubt there are many companies around that pay their programmers all the same amount anyway.


It's a tough question, but on general responsability usually is acknowledged by management. A managers salary is determined by the responsability she/he has and I think it applies to developers as well.

If developer Hanna handles a critical software (National Security System) she takes a higher risk if something goes wrong than developer Jill who handles a game application for iPhone. In this example, Hanna should be rewarded more than Jill if all other aspects are equal.


You pay your better developers more money regardless of project profitability. What criteria you use to define "better", is another question.

I don't think all the higher skilled developers should be on one team, so who gets demoted to the new product that isn't making any money yet. Two equal first year developers are now going to be compensated differently because of a lottery pick to get on the profitable team. You're getting into a merit pay system based on things you have no control over. Office politics are going to come into play and hinder moral.

This becomes another system to be gamed by the players just like lines of code. A better manager will politic for the greater reward. Imagine being a developer at Microsoft on a new product that breaks even, but you don't make as much money as a profitable team (because their app has years of marketing behind it) who made a bad release and didn't make sales projections. You don't reward the team that tanked the flagship product.

The high tide raises all the ships.


I am surprised how many people just assume that the person working on the strategic or profit driving application must be more qualified for that project than the person working on the low risk application. People here are also assuming this other developer takes part in the overall design.

All other things being equal, and assuming the two can be changed from one project to another with the same amount of catchup time means that they should both be rewarded bonuses the same for the same effort.


Programmers should be doing the hardest programming they can handle, and should get paid based on the difficulty of that task. On (almost) all applications there are easy parts and hard parts. People who can't program shouldn't get rewarded because they worked some really easy part of some very important application. Similarly, even if a project isn't important, if some really good coder did some difficult work on it, they should be rewarded appropriately. If a project isn't important enough to pay the developers an appropriate amount for the of the project, perhaps the company shouldn't be doing the project. Perhaps there's a cheaper way to get the same work done such as using an existing library (open source or paid license) or buying an existing software package.

Not the answer you're looking for? Browse other questions tagged or ask your own question.