Quote:
|
Originally Posted by Infinite Recursion
dividends = (amount)/(n+1)
Hmm.
This implies that all skill levels are the same. What if programmer A can type faster than programmer B and programmer C has more real world experience and is more knowledgable than programmer A and B combined? When C realizes that he/she has put in more work than A and B yet is paid the same... how long will C be part of the team?
|
There's that, and there's also the fact that the OP can't do basic math. Look at the example about a $500 project with three programmers. My math says
500 / (3 + 1) = 500 / 4 = 125
yet the OP gets 150. 125 != 150, and while I certainly wouldn't mind getting paid more than expected, if the person calculating pay can't do grade school math, I don't think I want to be a part of the team.
@OP: You might consider doing this differently. Say you get a customer that wants a particular system. They sit down with you (physically or virtually speaking), and you gather their requirements. At this point, you give them an estimate of how much the project will cost. You then sit down with your programmers, and do a rough task division (along the lines of A responsible for database code, B responsible for UI, C responsible for networking, whatever). It helps if these logical divisions are along class lines, as this will yield more robust code. It also helps if you decide on the interfaces between classes at this point. You can then negotiate weights, with each programmer receiving a share proportionate to their task weight.
As you can see, there's a lot that gets done before a single line of code is written. Also, there hasn't been any concrete project design, except for the possible interface specification. Now you can get back to your client with a revised estimate, one you can hopefully stick to. Bear in mind that, in the real world, project requirements often change. It's not at all unusual to have the client come to you when the project is halfway complete and ask you to add a certain feature, or change something you've already done. This is a key reason you need a contract that specifies (in detail) what the project will and won't do, when it should be complete, how much it will cost, and (importantly) a change policy. You also need the client to sign off before you begin work. Otherwise, you risk investing a lot of your (and your programmers') time, only to have the customer tell you they found someone else to do it cheaper.