The value of contractors and in-house software developers

In her essay “Why Work?”, Dorothy Sayers asks, what would labor look like if it were valued “not in terms of it’s cash returns, but in the value of the what the work produced”?

Here, I briefly attempt to apply that question to my year as a “hired gun” computer programmer. Instead of accounting for each hour, nay, each 15-minute chunk, I would instead have been paid based on the actual usefulness of what I produced. By this measurement, some days, 3 hours of careful work would yield $5000. At other times, slaving away for two steady weeks would be worth only 50 bucks.

The trouble is, WHO is qualified to make this judgement of a things worth? The answer to this question is often, truly: nobody. The client is often an idiot. They don’t know what they want. Now, in hindsight they are able to reasonably determine how valuable something turned out to be. Two years down the road they can look back and say “This thing was really useful and that thing over there turned out to be a big waste of time.” At the moment though, even the smartest ones are unable to make that call early on. It seems that with software, something’s worth is not well established up front. It’s value is imagined in dreams of the future. Clients picture in their mind’s eye how much time it will save them or how many customers it will attract. The reality though is always something different. So how can the software creator be compensated properly at the time the work is actually done?


It seems that it must be done through trust in his or her reputation. Has he consistently written lots of other useful things for other people? Then we will assume that he’ll write something good for us and we’ll pay him a lot of money for it. But there are so very many reasons why the thing is he building for you might be a piece of junk – not least of all the very nature of what YOU have asked him to build. And so everyone is working in the dark and exchanging money in the dark with hopes and dreams attached with strings to each feature request. What could possibly go wrong? Everything.

What is the cure for this situation? A long, long view – deep relationships that form over the years. There will be both bright years and dark years – predictable productive months and experimental risky months. At the end of the day, a good in-house developer (or very long-term contractor) is going to yield much better results for everyone involved that serially farming everything out to the lowest bidder or even the most reputable bidder at a given moment. The very best hired gun can only give you his best for a snapshot of time. Someone mediocre who has been brought in to the family over the years may ultimately be able to provide greater value in the long run. This requires greater patience, but that person has more potential to consistently produce valuable things over the years. The hireling on the other hand, is slave to the clock, slave to the invoice, and slave to the very temporary email account that was set up to interact with you. He promises big and may even deliver big, but only for a brief season.

In the end, my advice to those who need software written for them? Keep the forest in view. Don’t obsess over a couple of trees. Think 5 or even 10 years out, not just 6 months. It won’t get you on the cover of Fast Company, but it might mean that 5 years from now, your application doesn’t suck. An elite contractor may indeed be the solution to the problem you need to solve, but it’s likely that cultivating a long-term relationship with an in-house programmer or established shop will turn out better in the end. Don’t live like you’re going to die tomorrow. Lean toward investing in your local community.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>