Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Replace "delivered value" with "expected delivered value" and the argument goes through mutatis mutandis. Of course there are uncertainties in the value of unrealized work, but the company is paying because they think the expected value of the work is higher than what they are paying in wages.


So if the developer makes a mistake that lowers the delivered value, who pays? E.g. slower than promised development, things that were promised don't work at all or cost more for less results, etc.


Seems to me you've missed the point of the "expected value" part, throwaway.


Did I? So developers should be paid the expected value even if they do not deliver, is that what you're saying?


The chance that they won't deliver factors into the initial expectation and is reflected in the hiring and salary decision. You can evaluate this chance both globally and for an individual by considering their interview, past experience, recommendations. Presumably if a developer is routinely not doing their work, the employer will revise their expectation downward, and ultimately stop employing that developer if they are a net negative. I see no problem here beyond the inherent uncertainty that comes with working in a complex world where your knowledge is incomplete.

(edit to add: well, no problem except capitalism, but that's a story for another time)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: