I’ve been programming for 22 years. When I started Noverse two years ago as a professional software design and development company, I knew I would be competing against younger, cheaper programmers and masses of very cheap outsourced programmers.

A lot has happened over the past two years, and this article is about my own observations regarding the nature of this competition and how things have worked out for a lot of people I have spoken with who have chosen cheap.

tl;dr: They spent a lot more time and money than they ever imagined, and none have shipped a product. That’s right, none of the people I spoke with had shipped. In comparison, Noverse has shipped several client products of equal or greater complexity during the same period.

Setting the scene

A few times a month, I get a call or an email. It’s someone who has heard of me from someone else, knows what I do, has an idea and wants to talk to me about it.

I always take these calls. It’s how I get work. And it does not hurt to spend an hour or two talking to someone new, even if their idea is incomplete and they do not have the funds to execute on it. They tell others, I get more calls.

Most, like 95% of these, are calls by people who have incomplete ideas or no funding. For those whose ideas are incomplete, I spend the time helping them refine the idea, or point them at resources to get them help. Part of providing this advice is altruism, I really want them to succeed, part of it is selfish, if the idea pans out, maybe there’s work for me in it.

For those who have no funding, we talk about time and cost. Software takes a lot of time to make, and there is a lot of work that needs to be done. It needs to be designed, architected, built, debugged and polished. The artwork needs to be created, iterated on and incorporated. You need documentation, a web site, legal help, PR, a means of selling it, and a means of supporting it. This all costs money, usually a lot more than people expect.

Examining the numbers

One option for these potential clients is to go cheap. For the purpose of this article, I will assume cheap programmers mean young, inexperienced programmers or remote outsourced programmers. Let’s compare numbers between a graybeard and a cheap programmer.

Lets say the graybeard could charge $150 per hour for programming. The mathematics are theoretically easy, $150 per hour, 8 hours a day, 220 working days in a year, that’s $264,000 per year before tax. Sounds like a good living, putting them up there with the “greedy rich”. But the truth is that, as an graybeard indie, most only average around 50% time funded, with lots of time spent between client engagements (or in my case, working on the one freebie I do a year). Now we’re looking at about $132,000 per year, before tax (50% utilization). For a 40+ year old married graybeard, that’s a reasonable middle class income.

But this graybeard is competing against $50 per hour youngsters (or $88,000 per year at 100% utilization) who live at home, or $15 per hour outsourced folks (or $26,400 per year at 100% utilization) who live in cheap countries.

As you can guess, this graybeard and I lose a lot of potential business to these cheaper resources. The hypothesis is that even if the cheaper resource takes twice as long to do it, it still ends up potentially costing the client less.

Or so you’d think.

Results of going cheap

Fortunately, I have remained in contact with many of the people who I spoke to at the beginning of their experiences, and this is what I have learned from those that went ahead and went cheap:

• None have yet launched or shipped. Only one of them is close to it. And that’s because they luckily landed a cheap and great programmer, and the chap who’s idea it was is an amazing communicator. Remember, this is over a period of two years of discussions with lots of people!
• A lot more money has been spent. Some quit when they ran out of cash, others persevered, and have spent many times their original estimates. A few even shared how much. On average, they have spent about what Noverse would have charged, but have nothing to show for it.
• It has taken way too long. Given that only one is ready to launch in the two years I have been having these conversations, I guess infinite time is certainly too long. What I estimated versus what they were promised versus what happened requires a log scale on the graph.
• They don’t have time to do anything else. Because they spend their days babysitting programmers. They spend hours every day emailing or talking with their programmers when they could be working on branding, marketing, fundraising, eating and sleeping
• They made technical decisions without technical knowhow. They chose databases and service providers and technologies based on Google searches, whereas a professional programmer would have advised them what to do. The result is usually suboptimal.
• What they have received so far is terrible. Lots of badly worded emails, only parts of a product (if any) that looks bad, does not work properly and crashes all the time. A few even got a significant amount of core product written, but finishing it seems to be taking forever.

Part of the reasons we have been in touch is they have either asked me to clean the mess up, or find some way to manage it for them. I did one of these before, it did not end well. The mess was too big and I learned that I did not have the patience or skill to fix it. Lesson learned, will not make that mistake again.

In short, going with cheaper resources has been unsuccessful in that they have no product, have invested huge amounts of their own time and are out a lot of money.

Misconceptions of going cheap

Again, these are my impressions, based on many, many of these conversations:

Misconception: Even if it takes twice the time, it’s still much cheaper.

The reality is that it’s taking 10 times the time, not two times the time, or infinite time since none have shipped. To abuse a cliché, time is money. A lot more time is a lot more money.

And a lot of other costs are being ignored, such as the cost of your time to manage the cheaper resources, the opportunity cost of having a project delivered so much later (or never) and future maintenance and support costs.

Misconception: Fire and forget

Many clients believed that they could treat programming like a fire-and-forget missile, i.e. point the programmer at the target and let them fly. Or in other words, you tell them what the product should do, and leave them alone to make it. And somehow it will happen.

Most cheap resources do not have the knowledge, experience and expertise in product development nevermind your idea for this to be a viable approach. Cheap programmers need to be guided the whole way, to ensure they stay on the track you need. And they need to be watched closely to see that they stay on track.

Even experienced graybeards need guidance along the way. They know they do not understand all the nuances of the idea and that there needs to be discussion and experimentation and learning.

Software crafting is an ongoing conversation between client and developer, requiring time and contribution by both.

Misconception: You’ll get it in the estimated time

Most programmers, including myself, are supremely confident in our abilities, to the point of arrogance. As a result, we’re terrible estimators. Fortunately, most clients are wise to this, and usually double or triple any estimate given to them by programmers.

However, when it comes to cheap programmer resources, most clients get blinded by the cheapness and do not spend time trying to understand the given estimates or the project scope. They think that it’s so cheap, so it does not matter if the estimates are wrong. Several I spoke to never received a Scope of Work or a documented estimate in the first place. So they really had no idea how long it was going to take or cost.

More expensive programmers, like myself, are aware that cost is an issue for our clients. We strive to get the Scope of Work clear, and we use our experience to create better (but unfortunately not perfect) estimates. We also try to remain within the estimated time, often swallowing hours of billable time because we screwed up the estimate.

Misconception: You will get exactly what you need

Cheap programmers, and especially outsourced programmers, deliver what you tell them to deliver. They rarely contribute ideas, or even think about what they are doing. So, if you ask for something silly, they’ll spend the time making it. And when you realize it was silly, they’ll spend the time undoing it, then redoing it another way. More time, more money.

The key issue is that you think you are communicating effectively when telling the programmer what you need. But if they have a different mentality, or do not understand you and where you are coming from, they invariably misunderstand what you need, and deliver on that misunderstanding. Happens all the time.

People like me, who buy-in to a project, who have passion for it, contribute more than just code. We offer insight, advice, we think about the feature set and focus our efforts on making a great product for you. We make sure we understand. Then we make what you need.

Misconception: Misunderstandings are easy to fix

A common thread in all these discussions was that the programmer was told what to make, and they somehow made something else. As a result, the client had to spend hours and hours explaining what they had told the programmer to do and what needed to be done to fix it. And, after several days of programming, it was still not right, requiring another iteration, more time and more cost to fix things.

Some clients learned the hard way to communicate more explicitly, the remainder failed to learn this skill. Explicit clear communication is very very hard. Those that did learn had to struggle to find the right things to say to the programmer, living in fear that no matter how good the communication was, they’d still have to iterate several times on fixes, and pay for more hours. The remainder gave up.

This is how it should work:

Communicate the overall vision of what you’re trying to create for your customers, and any programmer worth their salt will bring their A-game to solve it from that shared understanding.
John Larson, JPL Consulting

Misconception: You will get a quality product

Most laypeople believe that if a program works, that’s good enough. Cheap, outsourced programmers do make things that work, and they do so cheaply, so that must be good enough. What a misconception.

Those of us who have been through the grinder know different. Software that works in one case does not work in all cases. It probably does not scale. It’s probably not maintainable or extensible. It’s probably not secure.

Software has an ongoing lifecycle. You do not build it and it’s done. You build it, ship it, fix it, maintain it, ship some more, extend it, enhance it and support it. A few users may grow into thousands. A single server may grow into hundreds. It may evolve in many ways. But the work never ends.

What you need for complex software is people who understand this and build an architecture to support this. You need people who take the long view, not the daily coding needs into account.

Misconception: Hang in there, it will work out

I sure hope so, but based on these conversations, it has certainly not done so for the people I have been taking with. Some are persevering, and I sure hope they succeed. But at some point, you need to ask if you are just throwing good money after bad.

So expensive is obviously better?

Um, no. If it were, Noverse would be charging $1,000 per hour, and I would not be shooting myself in the foot right now.

All kidding aside, really, the answer is still no. It’s not about the per hour rate.

Finding the right skills and the right kind of people is better.
The Hiltmon, now

Then pay them what they ask. Here is what to look for:

• Passion: A person who assembles Ikea tables is not a carpenter, a person who creates tables from raw wood is. A programmer who treats programming like any normal day job will produce code, but will not help you make a great product.
• Buy-in: A programmer who likes the idea of the product is more likely to ‘get’ the product and produce something nice versus the programmer who is just doing it for the money.
• Pride: A programmer that takes pride in their craft is one who will deliver good code and good product. A programmer who does it as a day job will deliver whatever code they can get away with.
• Problem Solving: A programmer who helps you solve problems, advises you on how things should be done, explains why things are, and interrogates you to ensure they have a proper understanding. Look for a thinker, not a doer, a collaborator, not a worker bee.
• Feedback: Programers have very logical minds, they see things differently and have completely different life experiences. A programmer who proffers ideas and feedback on your ideas is better than one that just does what you tell them to do.
• Opinionated: Look for programmers who offer their own opinions. These are the ones who will collaborate with you, not just work for you. Programmers with opinions seem quite annoying at times, but the work they do is so much better.
• Accuracy: Listen to how the programmer speaks. If they seek accuracy in your communications with them, and speak to you in very accurate terms, it means they are thinking and understanding. If they respond monosyllabically or in general terms, it usually means they do not understand you, or are not listening.
• Experienced: A programmer who has failed, made mistakes, and learned from them. One thing that completely boggles my mind is that for programmers, companies look for young, inexperienced, cheap resources, and get rid of them when they gain experience and cost more, thereby losing all the knowledge and experience gained. Can you imagine if we did that with doctors?
• A shipping mentality: Look for a programmer who wants the project to finish and ship. Most programmers don’t worry about polishing up and finishing the product, they just program. As long as they are programming, they are happy. Seek out one that wants to ship your product, it’s the only way it will get finished.

It all boils down to care. If the programmer is just doing a job, they do not care about the product. If the programmer has passion, buy-in, is proud of what they do, involves themselves in solving product problems, contributes their ideas, offers opinions (even argues with you), seeks clarity and accuracy and wants to ship as much as you do, you’ve found one that cares about what they do and about the your product.

To it, then

You may find care in a 22-year old for $50 an hour, or a grizzled veteran for $250 per hour. It’s not about the money. It’s about finding the right programmer to turn your idea into a viable and successful product, a product that works, is reliable, scaleable, useable, and maintainable, and then shipping it, supporting it and getting a return on your investment on it. And it’s about reducing the risk that the product will never get built, never finish, never be debugged, never be polished and never ship.

I am sure this has been done with cheap resources, look at most startups these days. But how many of these have released a successful product, or any product at all, without massive VC funding?

Based on my limited network, going cheap has not been a successful or even a viable strategy for the people I speak to. For them, going cheap simply cost more, took more time and none of them have a product at the end of all this to show for it.

Noverse does not compete on price. We care about our clients and the products we make for them. We have shipped and we continue to ship great products for them, and we do so at a fair and viable rate. Everybody wins.