I believe that the Technological Singularity is not near.  Moore’s law has a plateau point and I believe that we are fast approaching it.  It doesn’t matter if we can create computers with more processing power than all the brains on the planet if no one has any use for such a computer.  The stopping point of Moore’s law is that if there is a market that needs that kind of power that can exceed the cost of creating the next generation.

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.