eeh I'm not sure of your question as its a bit weird

1 hour = 1 hours of course..

Also a 'fast' programmer is not always (more often not) better then a 'slow' programmer.

If you are concerned about this when hiring NEW programmers just do on project base on smaller jobs and check their code and how fast they did it.

My personal standard is to only work by the hour. But to compare my hourly rate would be unfair, because everyone has to determine their own market rate. Your rate should be relative to rates normally charged in your country/region. Charge less if you have less experience, more if you have more. Do your own research and you'll have a much better chance of doing well.

And yes, 1 hour = 1 hour. Either use a stopwatch, or use an online hourly timesheet which tracks it for you. I use Odesk.

I almost NEVER work by the hour - why open a can of worms when you don't have to? The only exception to that is when I'm unable to reliably estimate how long a particular task will take. My clients NEVER see my internal timesheets for a project.

Working by the hour can often cause headaches. I use time management for all my clients and just charge one amount and give the clients a deadline. At least this way I keep taking in clients and not worry about hearing them complain.

I think that the best method is to hire programmers according to the tasks not the hours. The fix price is much more comfortable for you than paying them by hour.

You should actually know the quality of code the developer is writing and his efficiency while development, before you outsource the work. The hours for particular project is calculate by the developer himself of the Project Manager or a Team leader under whom the developer is working. As they understand better how long will it take them to do complete the task.
Later management decides the cost for the particular developer, depending on the Cost company is spending on the particular programmer. Management simply adds there profit and send the quote.

Actually in some cases we can't predict this work will be completed with in ---hrs. Because some client's made some changes after we completed that. We have to do that also.

As a programmer I have worked on several hourly and fixed prices projects. In hours based projects you usually install a time card software which records your time while you work on the project and also send screen shots of your screen to the client, to let your client know that you are actually working. But, personally I firmly believe that freelancing sucks, if a programmer hate his skills he can start freelancing to make them vanish. You become a good programmer when you experiment a lot unluckily the freelancing clients don't let you do it. Instead you should get different kind of projects based on certain business logics by selling your services or make your own products. This is best

As a software developer I can say that it truely depends on the honesty of the person as luckyman#9 said. You really have to build a relationship with the person. I only work with clients I enjoy working with, I love my job and would never overcharge them on fixed price nor on hourly price projects. Do a small project with the person, maybe a few hundred bucks at stake, see how it goes.

An hour is an hour. There is no standard rate, if that's what you mean.

I'll assume that by slow vs fast you still want quality regardless of how fast they churn out code. That being the case, if quality is equal, it just comes down to rate.

Suppose Programmer Slow Joe charges $50/hour and Programmer Lightning McQueen charges $100/hour.

Slow Joe tells you it will take him 3 hours to do the project and McQueen says it will take him 2 hours.

In this case, Joe will charge you $150, but McQueen will charge you $200. Essentially, you are paying a premium for getting the job delivered sooner if you go with McQueen.

In reality though, quality varies. A lot. And you can't tell by the speed of the programmer. As a career software developer, I've seen fast sloppy code, fast quality code, slow sloppy code, and slow quality code. I've seen it all.

I've seen code that works, but can't easily (inexpensively) embrace new features.

So really, what are your requirements? Does it just have to work for this project? Plan on adding stuff later? Are you selling it as a one off? Will you need to support it?

Software is complex. Typically, the more you are paying, it is because you are paying for the experience and wisdom that will help ask the right questions to make sure you get exactly what you need. The old saying definitely applies here: You get what you pay for.

So great, you say, now what?

Get referrals. No matter who is doing the work, get referrals. The more sizable and complex the project, the more you want to lean on a higher rate programmer. The smaller and more "throwaway" the project is, you can pay less and require less referrals.

I learned over the years if it is fixed fee then make my best estimate and double it. Also, never deliver anything without a firm contract in place with progress payments.

Also, if they did not have an rfq (request for quote) I would offer to write it as time and materials for them being sure to anticipate featureitus (could you just do this one little change) Many times the project manager would call requesting a "minor" change and I would point them to the spec saying that it was beyond the scope of the job, but I would be happy to bid on a change request.

One difficult client called me 7 months after delivery with a bug that they wanted fixed (I gave a 6 month window for free bug fixes.) Told them I would call back, verified the bug and fixed it in about 10 minutes.

Called back and told them it was a very difficult bug and it would cost $2,000 and take two weeks to fix it. They agreed.

Marked my calendar. Two weeks later delivered the fixed software and invoiced them. They were happy to pay.

Normally, I would have just fixed it, but they had given me so much grief during the development phase that I felt entirely justified.

My other advice is don't be hungry to the point where you will take almost any job at any rate. Learn to recognize certain personality types like the "chisler" and be willing to walk away. Some people are just psychic black holes and will suck the life right out of you. You are much better off to just say "See yah, by" Then don't answer their calls or emails.

Just my experience. Some lessons cost more that others. Good luck.

Determining how long a project will take comes with experience and familiarity with the project's technical challenges.

When I analyze a new project to determine how long it will take, I look at the project spec and then compare it to past things I've worked on. From there, I can estimate if it's going to more time, less time, or about the same time.

If it's something new that I've not done before, I try to break the project down into sub-projects, and then estimate each of those sub-projects independently. Then I will add up those estimates to get a total estimate. For the sub-project that contains the new technical challenge, I will just guess, and pad it around 25-50%.

When it comes right down to it, estimating project duration is all about SWAG: Scientific Wild A__ Guess. You don't just guess, but do your best to guess based on previous performance.

Once you have an estimate, then you can calculate how much to charge a client (or report back to your boss if your not a freelancer).

For fixed fee, pad your SWAG a little bit more to account for client changes (which will happen) and unknowns (which also happen) and other unforeseen challenges (yes, these happen too).

For hourly, it's less of an issue as long as you communicate when you run into a snag that will cause extra hours.

You make an excellent point ClicProject about underestimating. I had a manager who mentioned to me that I tend to underestimate too much and to start padding in extra time, especially when I'm computing estimates for a team and not just myself.

I am not a programmer but I do web design and I calculate my work hours by the moment I start the project til finished. Whether it takes half a day or half a week just add those hours up!

Programming slowly is actually not a bad practice. This allows you to make sure that the code you wrote is accurate and doesn't contain errors.

I work as a software developer and we give estimate in days for the client ( a day is 8 hours) . It's better to overestimate than underestimate. The project manager usually consults the developers to inquire about the amount of time it would take to do the development. You also have to add analysis, testing and a buffer (in case something unexpected happens) time in your estimation. If you are a project manager it would be good to use a methodology called "Scrum" every mourning where all developers will talk about what tasks they accomplished yesterday and what they plan on accomplishing today.

This is always pretty subjective. I like to hire programmers based on a fixed priced, so I know exactly what I'm paying. Hiring and paying by hours tends to get a little confusing for both parties.