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.
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
|||
|
|
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. |
|||||||
|
|
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. |
|||||||||||||||||
|
|
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. |
|||||
|
|
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. |
|||
|
|
