That's a lot of complexity. Pay structures for sales people tend to be reducible to a couple tables or a formula. There's also a more subtle difference: a sal

That's a lot of complexity. Pay structures for sales people tend to be reducible to a couple tables or a formula. There's also a more subtle difference: a sale is a discrete event, so there is a known point at which we can determine the goals have been fulfilled. Software is a living thing -- its quality can only be inferred with time. What about bugs? Flexibility to adapt to changing business requirements. Ie: if I anticipate that we will need to change out component x so i don't tightly bind to it, how do I get compensated for my foresight, when this adds a minimal amount of overhead to my development practice? By incentivizing the completion of objectives, you are asking for the buildup of technical debt. The objectives of a salesperson (not customer relationship manager or marketer) are necessarily short-term. The objective of a healthy development organization (as I see it) is to consistently produce high-quality software that meets business objectives in a predictable and transparent way. Programmer productivity structures almost always have or create the development goal of "meet short term objectives quickly", which is a kiss of death for long-term growth and programmer satisfaction once you have to deal with the organic mess all of the shortcuts have created.