Even now, the CEO of Ubisoft recently said that the next generation of game titles will cost and average of $60 million to make (and this is an estimate before hyper-inflation starts to hit the U.S. Economy.)  Just how many people would have to purchase the game for over $60 for the producers to cover production cost, much less the cost of marketing and distribution?

One such way to cut down on costs is to outsource.  However, outsourcing has serious issues and among them is that you cannot keep the price of talent down because of the demand.  For instance, in the Philippines, one of the largest places for outsourcing talent, you are hard-pressed to finding a software architect or product manager with 10 years of experience.  Why?  Because they have moved out of the country.  In fact, it is an initiative for the Philippines to create incentives to keeping talent within the country or to return to the country rather than have all of its talent move away for greener pastures.

What I had conjectured in a previous post is a solid fact of many third world countries.  Talent simply leaves to go where they are paid more and live a better standard of living.  Those who seek a “better standard of living” generally aim for living an average life in first-world neighborhoods than seeking a life as a king in a third-world neighborhood.  This creates a “brain drain” effect where talent simply flees a developing country.

To the indie, this means an opportunity.  There is going to be a substantial market gap in the next few years for inexpensive, innovative and outrageous games that only indies can provide.

Software Engineering Explained (click for full size)

An old picture that is passed around by Software Engineers, but is worth repeating.

“It was late 2003, and a contractor, Science Applications International Corp. (SAIC), had spent months writing 730,000 lines of computer code for the Virtual Case File (VCF), a networked system for tracking criminal cases that was designed to replace the bureau’s antiquated paper files and, finally, shove J. Edgar Hoover’s FBI into the 21st century.

“It appeared to work beautifully. Until [Zalmai] Azmi, now the FBI’s technology chief, asked about the error rate.

“Within a few days, Azmi said, he warned FBI Director Robert S. Mueller III that the $170 million system was in serious trouble. A year later, it was dead. The nation’s premier law enforcement and counterterrorism agency, burdened with one of the government’s most archaic computer systems, would have to start from scratch.” – Washington Post (Dan Eggen and Griff White, 2006).

You hear it a lot in the news when massively expensive software systems fail: The Mars Orbiter Crash, The Denver Airport automated baggage claim system.  In 1994, the software project failure rate was measured at over 30%.  And only a reduction in the size and scope (read: complexity) of projects has reduced the failure rate to 15% by 2004, that is still a stunningly high number.  In other words, one out of every six software projects are doomed to fail.  And this does not count the number of software projects that are “challenged.”  That is, a software project that is late, over-budget, and missing critical features or requirements.  That number is over 50%.

Ready to fail!

How can this be?  The answer is simple: Software Engineering is not easy.

You can never assume that the client can explain what it is they are looking for, even writing out hundreds of lines of requirements describing what it is they want. It’s completely different describing something and seeing it in the flesh.

Now, assuming that the software engineers are meeting you – the client – every week, face-to-face and speak the same language, how much more difficult would it be if the engineers were working at the time you are normally asleep, you can’t even see unless you make an overseas trip that is over 12 hours long, and whose first language isn’t the same as yours?  How many more problems, misunderstandings and delays can you cause?

Language is also an interesting factor in terms of outsourcing.  English is a low-context, highly descriptive language compared to other world languages.  In a particular study of Thailand and their software development practices in 2005, it was found that software practices that relied heavily on documentation were impossible to implement in a culture that has a high-context, low-descriptive language.  It was virtually impossible to implement any real documentation and communication of requirements because the language of the culture itself relied heavily upon a person communicating the context of it to you and not just the content.  Imagine trying to outsource to company in a culture that cannot capture requirements in a document because it lacks context.

The break-neck speed and intensity of game programming doesn’t lend itself to much room for error.  In some ways, it is like modifying a rally car in the mid-motion while it is racing around the track.  And if you have to stop and explain the difference between “taking a break” and “taking a brake” to a fellow engineer, that may be the crucial difference in what splatters you all over the race track or wins the race.

Ganesha's Arms help him code faster than you.

Ryan Henson Creighton of Untold Entertainment posted an article on freelancers versus outsourcing to India.  He had this awesome picture and caption of Ganesha that I had to duplicate it on my blog.  The gist of his article was lamenting how a team of outsourced programmers can create tons of “top-notch” websites for pennies on the dollar compared to their western (read: expensive) counterparts.

My hope is to dissect this fear one piece at a time in a series of articles and reasons why not every computer job or freelancing gig will suddenly find itself in India.

Firstly: Computer Programming is NOT based on the factory model.

A lot of software engineering practices and models of operation seem to base themselves on the theory that computer programming is like a factory model that can be scaled with more labor.  This is a horrible analogy, but this meme is unfortunately repeated by many management teams across the software engineering landscape.

Probably one of the best and most accurate analogies of software programming comes from “The Mythical Man-Month.”  Programming is more like a “surgery” table than it is a factory.  Most complex systems act like a body with all its moving parts working as a whole.  And because a program works as a whole with all its moving parts, there is only a limited number of things people can be working on at a time – much like having too many surgeons working on the same person on the operating table.

This is the first place that you find that you cannot simply purchase more people and solve a complex problem quickly.  In fact, having too many people may slow down the process rather than speed things up.

Secondly: You can’t outsource talent.

Now taking the surgery analogy further…  Would you outsource your heart surgery to someplace cheaper?  Does a cheaper doctor mean you will have a better surgery?  People will not buy things simply because they are cheap.  Depending on how much they value of the end product, people will still pay top-dollar for a good result.  “You get what you pay for,” is very true in this field, and I have heard a few stories from freelancers who have had to clean up or redo messes made by outsourcing.  The fact of the matter is that people will pay for talent.

Dr. Evil

The reverse is also true in that talented people will not price themselves cheaply.  Why would a highly-skilled and talented person in India not charge equal to or just under their more expensive counterparts in the West and live like a king with a lower cost-of-living?  A person of a certain skill level will not undervalue themselves in the market.  To quote Dr. Evil, “Why settle for millions when you can make billions?”

So unless you are developing a computer program that easily fits under the mold of “easily replicatable” like some sort of template that you can replicate a million times over, I don’t see outsourcing as necessarily the best choice.

And if anything… GAME PROGRAMMING does not fit this category.