How should you evaluate programmers?
Can you evaluate programmers like carpenters (or other tradespeople), where you have good ones and bad ones, but the time required to complete a job doesn't vary widely? No! The difference between mediocre, average, and good programmers is staggeringly huge. Using the carpenter analogy, imagine a team of 5 carpenters that can build a house in about 6 months. If carpenters were like programmers, you would find a team of two or three that could build a BETTER house in a week. And a team of ten that would still be stumbling along after a few years, and could never complete the house no matter how much time or money they had.
How and why this is possible can be found here: http://www.joelonsoftware.com/articles/HighNotes.html
Billing is billing, right?
Some contractors/companies bill when the day starts, and make sure that the clock is ticking for a particular client as much as possible. At AppVizo we only bill when we are actively engaged in solving a problem for the client. We do not bill for any item not directly related to addressing a stated problem as found in our project/bug database. If we need to learn a new technology to solve a problem, we do it on our own time.
Couldn’t one really good programmer complete my project?
If my programming project is behind schedule, should I hire more programmers?
In programming this is known as "the mythical man month" and was documented over 40 years ago by Fred Brooks at IBM. At one point his book was required reading for all Microsoft managers so that they understood the implications of Brook's law: Adding manpower to a late software project does not help. https://en.wikipedia.org/wiki/The_Mythical_Man-Month