“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.