5 ms·

LOL, you just don't know how to estimate how long it's gonna take, or you don;t specify what needs to be done well enough. Lots of people work for a fixed pric

by gm 17y ago

LOL, you just don't know how to estimate how long it's gonna take, or you don;t specify what needs to be done well enough. Lots of people work for a fixed price with happy clients and they end up being happy with the outcome too (myself included). The key to everything is to be good at specifying what needs to be done, and then be good at estimating how long it will take you to do it. Also, lots of clients do not want hourly, because THEY feel it is unfair. They do not see you working, and you could be taking them for a ride.

Confusion 17y ago
Specifications, paradoxically, always lack specificity. There are always lots of things you can get into an discussion about. A good client understands that specifications change, that work is incremental and that you wish to be paid accordingly. Every experienced developer should know that nobody knows how to estimate how long something is going to take. Even the best developers I know always fudge their numbers by a factor of 2 and that is after they have sliced the work down to parts that take at most 4 hours and used all other tricks in the book to get decent estimates. You add everything, add 50% for writing the tests (either before or after the actual code, that doesn't matter), add another 50% for meetings, discussions, etc., add another 15% for writing documentation and then double it all. I will never take a fixed-price job, unless I'm sure the client is reasonable in his expectations and I can apply the above calculation while still ending up with a decent hourly rate. I'm currently employed, but my employer isn't doing too well...
- gm 17y ago
  I thnk we are talking about the same thing... Based on estimations, it is always a goods idea to add a certain room for error, additional expenses, etc... I did not say multiply $20 times the number of hoiurs, I just said that you need to derive your fixed price based on your estimation (not DIRECTLY based), which in turn is based on the specifications/requirements. So we are in agreement. My beef was with the assumption that the service provider always gets screwed if they charge a fixed price; my point was that that does not need to be the case, if you follow a solid process to give your estimate.

by gm 17y ago

Confusion 17y ago

Specifications, paradoxically, always lack specificity. There are always lots of things you can get into an discussion about. A good client understands that specifications change, that work is incremental and that you wish to be paid accordingly. Every experienced developer should know that nobody knows how to estimate how long something is going to take. Even the best developers I know always fudge their numbers by a factor of 2 and that is after they have sliced the work down to parts that take at most 4 hours and used all other tricks in the book to get decent estimates. You add everything, add 50% for writing the tests (either before or after the actual code, that doesn't matter), add another 50% for meetings, discussions, etc., add another 15% for writing documentation and then double it all. I will never take a fixed-price job, unless I'm sure the client is reasonable in his expectations and I can apply the above calculation while still ending up with a decent hourly rate. I'm currently employed, but my employer isn't doing too well...

gm 17y ago
I thnk we are talking about the same thing... Based on estimations, it is always a goods idea to add a certain room for error, additional expenses, etc... I did not say multiply $20 times the number of hoiurs, I just said that you need to derive your fixed price based on your estimation (not DIRECTLY based), which in turn is based on the specifications/requirements. So we are in agreement. My beef was with the assumption that the service provider always gets screwed if they charge a fixed price; my point was that that does not need to be the case, if you follow a solid process to give your estimate.