In my post on BizSpark, I suggested that while $1 in hard cash can be considered equivalent to $1 in programmer effort, practically they are quite different. There are a few different situations around this, so let me try to explain them here. For the sake of this discussion, let me use some round numbers, such as a programmer costs $100 an hour, ignoring differences in geography, skills, and a programmer works 2000 hours a year, ignoring holidays.
So let’s say that you are such a programmer. You are at home deciding whether to cook or order a pizza. One way to think about this is: You make $100 an hour and it would take 30 minutes to cook a dinner, but no time is wasted ordering a pizza. Compare the $50 for the 30 minutes versus the $20 pizza and you have your answer: Order the pizza every time. Obviously, this doesn’t work that way, because you will spend the next 30 minutes watching TV and instead of earning 50 bucks, you are simply out 20 dollars.
In this situation, your effort is not directly translatable into money simply because your effort is not valued at the same rate all the time. If you could convert every hour of your time into directly producing revenue, then such a determination could be made. For example, you may be working from home and be able to bill every hour you work without any overtime constraints. In such cases, you could choose to work instead of doing some other chore, earning more than you would be spending.
But generally, people have two different values for their effort: one while they are doing their company work ($100/hr in our example) and another at all other times ($0/hr). Spending more time to accomplish something when there is a faster solution (that costs money) available may be preferred in the first circumstance, but not so in the second situation. This is one reason why many startups choose inexpensive solutions like LAMP. Their effort brings close to $0 an hour. Any tool they purchase could speed up their work, but it is money that has to be spent upfront.
This is not necessarily right or wrong. I am just describing what happens. That is the way that almost all startups operate: with a tight budget. Some survive and go on to bigger things. Others are under-capitalized and do not make the necessary investments to go to the next level. Peter Drucker has described this growth problem with startups: they often stick to the same operational model that worked well during their earliest years. The founders do not understand when they have to change their management and financial structure to become a bigger player. Quite often, the founders have to be forced out for the company to make the necessary investments and structural changes.
Employers make several different mistakes when calculating the value of a programmer’s time. One is that they take the expense of salaried programmers for granted and pay very little attention to maximizing their productivity. Almost all companies treat permanent employees and consultants differently because the cost of the latter is treated as a “special” expense and has to be accounted for more diligently. Employees are often given a pass on actions or inaction that would get a consultant fired on the spot.
Of course, some employers go the other extreme, trying to suck every ounce of work from the employee, making them work long hours and being on call. Practically, this is useless. Employees give their body, not their spirit. A programmer may spend 12 hours in the office, but actually perform only 6 hours of work and introduce bugs that take another 6 hours to fix. I won’t deny that there can be some short-term gains, but it all evens out in the long run with no gain in output and a greater risk of damage to products and human relations.
The shorthand of using programmer cost per hour can be misleading. Of the 2000 hours that a programmer spends, he will be most productive in some of the hours and very unproductive at other times. For example, a programmer who is an evening-person may start his day by clearing out his desk, sending official emails and participating in meetings, i.e., not producing any code. But after 2 pm, he gets into a flow and starts writing the code for his tasks.
In the above case, the programmer’s evening hours are worth a lot more than his morning hours. If the employer causes the programmer to be disrupted by phone calls and meetings during the evenings, he has changed the value of the programmer’s hours from a high value to close to zero. This may not be evident immediately because the programmer seems to be doing the same tasks as he was doing in the mornings.