[Ted S]

Originally Posted by legionofangels

I am a Sales Executive for a Corporation, I know big whoop is the reaction of many to that comment. But I know how the game works, because I see it on every job we contract. Ok, job costs $15,000.00 USD, Builder Payout is $3000.00 which equates to like 9 days building time, "builder you have 9 days to do the job, if you take longer you make less money, if you get it done earlier you make more." Of course our high standards of excellence in construction have to be applied to ensure customer satisfaction. But I understand what you're saying.

You and I probably work in a very similar world so no, I don't say big whoop, I say where's my next nice lunch meeting.

I think we agree for the most part... coders should deliver on time, work efficiently and come close to their estimates. Hourly rates allow for more accurate billing but if nothing is allowed to be changed (or in the case of a small project of just a few hours), a fixed estimate makes perfect sense too. If the coder wants a higher rate, well, that's up to the client to decide and neither neither here nor there.

Paying people to learn isn't ok... paying them for more quality, thoroughness and a better system is however perfectly acceptable (there's more to code than speed... sometimes you can be fast and write well, sometimes it takes more time to minimize impact and be something that can be built upon in the future).

No coder should be paid if they don't deliver unless the client did something (i.e. stopped making scheduled payments) to stop them. A contract is an equal exchange... I pay my coder, they deliver. Paying parts upfront is just a means of insuring I'm not a complete flake... not to give them money to do half a project, they don't finish, I will come after them.

My point was simply that people hiring out should no more expect to get great work for pennies than coders should expect to get open ended projects that don't have deadlines and can be overcharged.

The best way to insure things work out is to fully outline needs. In a smaller project (under a few thousand) this generally means mocking up the changes, defining any functionality not showable in mockups and writing down expectations to be reviewed. For anything mid or large sized, a more formal design process can be applied but in either case, requirements are the key to success. If they're not there, they can't be met and if they are there, they must be met. Anything else and one side has failed to do its job.

I should add... most of the engagements I took back in my consulting days were based on some sort of base with a performance incentive/ earnings split for results. Now I'll grant that I'm a marketing professional who codes here and there but for me and my clients it worked out much better than paying me by the hour and only getting my expertise until the hour ended. Under this scenario it was in my interest to meet and exceed requirements plus add more input in features, functionality and design to insure success.