IrresponsibleUseOfFr's Journal: Reflections on the Gaming Industry

I've ended my employment at Electronic Arts and am currently in progress of moving to a new job. In the time in between, I would like to take some time to expound on software and particularly the challenges the game industry faces. I have recently begun reading "Dreaming In Code" by Scott Rosenberg. I can already tell that I am going to like the book. But, the central question: Why is software so hard? Has already been answered, many times in countless ways. People expect there to be some magical answer: if we just click our heels three times before we turn on the computer then we will write bug free code for the rest of the day. Life just isn't that simple, and software isn't that simple. A computer, by design, is not fault tolerant when it comes to software. It just does what it is told, slavishly and literally. If the computer does notice something is messed up, there must be other code to tell the computer how to handle it (usually it is terminate the application or hang the machine). But this begs the question, how does the program detect that it is in an invalid state? How do you know that the code that detects the invalid state won't get into an invalid state itself?

Yes, this is an infinite regress. And worse yet, for what would seem to be trivial problems such as: "Does this program give me an answer and quit?" It proves to be mathematically impossible to write a program that is up to the task for all cases. Add to that, that certain popular programming languages like C/C++ go out of their way not to detect programming errors at run-time, and we see glimpses of a dark side to the kingdom of software.

So, I'll reiterate: Why is software so hard? Hubris. It is hubris so flawed that in some cases it is criminal. I've seen projects destroy marriages, people's physical and mental health. Software demands respect because it can cause misery, stress, and can destroy your life. The same might be true for any job, but I think it is an acute problem in software, and frustratingly self-inflicted.

Along those lines, I would like to reiterate insights that I have experienced and read about and apply them to today's challenges in the game industry.

I am going to format them into a few sections that I'll be posting over the next couple days. The major topics I plan on covering include:

• Problems Faced Due to HD-Content
• Problems Faced Due to Developer Taxes: Part 1 Features
• Problems Faced Due to Developer Taxes: Part 2 Concurrency
• Quality, You Need It.

For final thoughts, if hubris is the plague of software, then modesty is key. Software isn't just about getting the big things right, it is about getting the big things, the miniscule details and everything inbetween. You need strategy, tactics and most of all execution. Because software is "pure thought-stuff," I think it is harder for people to realize that they are asking for an equivalent of a Rolls-Royce using parts from a scrap-heap with two people and a month to do it in. I don't blame the people who would like to think they could build the Roll-Royce for cheap. I don't even blame the hucksters who make their living convincing the Rolls-Royce loving crowd that it is possible to do, if they would just use WizBang Process 2.0. And I don't blame the two poor workers that are given an unworkable situation, since they might not even be aware that it is impossible at the outset. But, the fact of the matter, the project is doomed from the start. The tragedy of the situation comes in the friction between the schedule and reality, and the disasterous tug-of-war that it can play on the two workers lives. A more thorough discussion of this phenomenom and what can be done about can be found in "Death March" by Edward Yourdon.

But, more importantly, I don't believe software death march's are productive. I understand "Parkinson's Law": work expands to fill the time available for its completion. And I do believe it happens, but projects that get behind tend to fall into new realms of ineffiencies, patch-work, panic and crisises that can not be justified in the name of avoiding "Parkinson's Law". For more about accurate software estimation, I would recommend: "Software Estimation: Demystifying the Black Art" by Steve McConnell. Doing the due diligence on feasibility is the first step to avoiding it. I will say, I have deep respect for managers that will put their neck on the line and tell an executive that something isn't possible instead of passing the buck to the workers. Too bad there seem to be so few willing to do so.