Continuing in the series, we are now onto problems faced due to concurrency. I think anyone that has experience in the area will agree with me in saying: concurrency is hard. The bugs can be very vicious, since they can be timing related. It is also possible to run into situations that really are not bugs but substantially interfere with enjoyment of the game, for example overloading one part of the system so that it becomes a bottleneck.

It is hard to predict which part of the program will be a bottleneck and programmers are infamous for incorrectly guessing where the program's bottlenecks lie. Additionally, these problems can be extraordinarily transient, based on interactions of competing threads, up to and including classical concurrency problems such as deadlock and priority inversion.

Additionally, dealing with concurrency means making a number of trade-offs at a high-level. That is choosing a strategy and coming up with an architecture that embodies those choices. What processes and data live in what thread? How is communication handled between the different threads of execution?

Ultimately, moving to concurrent systems is not an instantaneous win like getting a processor that processes more instructions per second. There are inefficiencies that exist in concurrent systems, like synchronization and buffering that simply don't have to dealt with in a single threaded context.

How a game approaches concurrency is another challenge. One obvious way is to use threads is as mini "servers." The best choices for what to turn into a server is one that manages output that doesn't have to be fed back into the game immediately: such as a "sound" server, a "graphics" server, or a "network" server (for outgoing traffic). Finding high-level tasks for each server is paramount. The building up the message to the server for the task and submitting it, must be cheaper than actually performing the task in order to realize the win.

This approach works fine for the XBox360, but not for the PS3. The PS3 contains many special purpose processors, that basically require small programs dma'ing memory to produce some output. One approach to utilize these SPUs is to make a job, that is, a batch of data and a program bundle that is executed on one of the SPUs in a pool of all the SPUs. The coordination effort involved in teasing out the concurrency is significantly more difficult. For example, one might have a job that evaluates animation on a mesh. At some point there needs to be a return trip on the job, that is, in order to do useful work, the job must finish and the result fed into another process to cause the desired side-effect. This wasn't necessary in the server case, in fact, the servers were explicitly designed to avoid the need for round-trip communication. The limiting factor of performance is that the driver thread must not spend its time waiting for the job to complete. Not an easy feat since the whole point of sending it off to another processor was because it will take a while to do. Finding useful work while the job completes is no small feat, and requires some significant cleverness.

Getting peak performance out of the PS3 is going to take awhile. But unfortunately, PS3 consoles aren't exactly selling like hot-cakes, which brings up a dilemma. Good games will drive PS3 sales, but good games will take a long time develop. Will the PS3 survive the lull? Only time will tell, but Sony does face a chicken and egg problem. It is hard for 3rd parties to justify large development budgets for consoles that don't control a large percentage of the market. However, it is hard to control a large percentage of the market without the games to drive the sales of the console (which is why having a good launch is crucial). At this point, Sony's best bet is to drive adoption of PS3 themselves with 1st and 2nd party titles. Sony might get lucky, but it is probably not the best business strategy.

In conclusion, concurrency is hard. Concurrency has a large impact on architecture which forces migration or adoption of new technologies. Concurrency opens up new classes of bugs that can be hard to kill. These forces conspire to push development targets out, making games more costly to develop. We have looked at what architectures one might adopt, "server" or "job" based. "Server" will work well on the XBox360, but not so well on the PS3 because the SPU's are not symmetric. A "job" based architecture will work for both platforms and on that ground, the PS3 should start out performing the XBox360 because of its higher theoretical peak performance. Although, a "job" based architecture is harder to implement. Sony in particular will need to justify this higher development cost, their best way remedying the situation is with killer 1st and 2nd party titles, which will drive extra console sales and justify the additional expense to 3rd parties.

The first part of this series of essays dealt with productions costs due to HD. Although, HD can be considered a feature in the marketplace of other possible features, it impacts artists more than programmers. It is my belief that artists can be added to a project late in the cycle, be given sufficient training to produce quality content, and work with mimimal communication between each other, thus avoiding "Brook's Law" of "adding manpower to a late software project makes it later."

But a related issue is: what about programmers? In next-gen games a number of complicated features are required to gain traction in the high-end. Examples include: Multiplayer (split-screen), Online Multiplayer, Graphics upgrades like (real-time shadowing, image post-processing), and a lot of features that people find in other games like character creation, customization. This is not necessarily a bad thing from a consumer point of view, but it does cut down on innovation. Time spent getting online multiplayer going is time not spent tweaking the AI for single-player. Time getting graphics features up to a level that it is competetive with other games on the market (like Gears of War or Resistance: Fall of Man) is time not spent on an innovative gameplay mechanic.

The days of starting a game from

int main(int argc,char* argv[])
{
return 0;
}

are over, it just isn't cost effective. There is too much work to be done, too many decisions that have to made and implemented. Despite the plethora of "good" libraries that are available on each gaming platform, the really hard problems are left up to the game. Is the game going to be client-server based or controller passed? How does it handle animation (bone or vertex based)? What systems are inplace to help optimize load times? How is the UI authored, and how does it interact with the code? What tools are around to monitor memory usage?

The solution is to start with a code base that answers and implements a large number of these questions in a way that will work for the product. The viable alternatives usually are: license a game engine or port a current-gen game to next-gen. Starting from first-principles and game platform libs is a more expensive way to begin. Theoretically it could be justified to write a custom game engine, assuming it would be used for multiple titles. However, most underestimate the significant cost, risk, and the fact that many organizations are incapable of doing it in a way that will be cheaper than buying an existing engine or porting. In fact, I will say most organizations are incapable of writing a game engine more cheaply than just buying one or porting existing code. I will even go as far to say, the more people involved in the engine, the less likely it will be a success.

When faced with the dilemma of many features and the mentality of starting from scratch (or we can do this ourselves in two weeks and it will be loads better), the unenlightened response is to add more programmers. There are certain reasons why I believe having team sizes of much greater than 10 programmers is a bad idea in the game industry. The first thing is that games are a very competetive market-place. It is important to be agile to survive and smaller teams do a better job. Secondly, designs are frequently subject to change. A perfect design on paper can turn out clumsy and no fun when actually implemented. It is important to adapt to that. Third, the game industry really feeds off passion. It is tough to have qualities like ownership, accomplishment and identity with a product if you are 1 person in 40 working on it. Responsiblility diffuses on large teams so that no one feels responsible for anything.

An objection might be the battle cry of: design better, dammit! I am sympathetic, but I think people's ability to see into the future is extraordinarily limited. And dogmatic adherence to design first leaves out prototyping which I belive to be just as important. A good design does not come out of a vacuum. The best decisions come from trying a bunch of different ideas out and selecting the best. Design vs. prototyping is frequently put as an either/or proposition. And it is to a certain extent because they both eat up wall time. Both need to be bounded and both should happen before development in earnest, yet there are a few outcomes to prototyping that must be addressed. One, it is tempting to take a prototype for a feature and turn it into a real feature. Two, for some features, it takes longer to describe how to implement it than actually implementing it. The best approaches is to do the design also. Do not attempt to get the prototype completely working in the design phase. Write a design based on what was learned, estimate the remaining hours of work and place the code for prototype in a patch file. For designs that take longer to write than to implement, I think a design needs to made regardless. For trivial tasks, the design should be trivial. But, more times than not, the programmer will go down a hole, and the programmer is left in midst of a mess, without a proper amount of time to fix the problem (because it is in the design phase after all) and without a design that another programmer could have pointed out the issues with during a review. Which is to say, all designs are worthless (from a design stand-point) if they are not reviewed. An unreviewed design effectively becomes notes about a task instead of a plan for attacking the task. Working on tasks for unbounded hours defeats cost benefit analysis which I feel is essential for enlightened product development.

The last thing that I would like to state about large development team sizes, is that brings about a situation where no one has a clear idea of what tasks are out there, what truly remains to be done and what the impacts are. This inability to grasp the whole picture at a reasonable level brings about churn since the left-hand is totally unaware what the right-hand is doing. When something happens to cause a collision, the planning starts being reactive to problems instead of provactive in avoiding them. These critical stops in the schedule due to unanticipated and unscheduled issues cause the types of unproductive periods that are the goals of avoiding via implementation of good process.

One particular problem that faces the game industry is the challenge poised by HD. Simply put, one could estimate that the XBox360 is ten times as powerful as the original XBox. However, it would be a mistake to believe all of that power is solely at the developer's disposal. One reason is the developer tax of HD. The framebuffer for the XBox to support progressive scan is 640x480. For the XBox360 a framebuffer of 1280x720 is required (three times as many pixels).

The point that I'm trying to make, and this might seem exceptionally crude, is that all the power of the high-end Next-Gen consoles is not being used to solve the same problem (unlike NES, S-NES, N64, to GameCube). High-end consoles and by corollary their games actually have to solve a larger problem. Simply put, the target moved.

This higher fidelity output requires higher fidelity input. More detailed textures, more detailed models, etc. At the end of the day, every single one of those texels or verts will be touched by a human being. I don't hold out much hope for procedural texture synthesis saving the too much labor on the texture end. Procedural texturing may take it 80% of the way, but I think there will always be a need for a human to twiddle with the results and clean up the artifacts. Procedural texturing is a tool for an artist to use, not a replacement. I think similar arguments can be made for other asset types that require higher fidelity.

The conclusion is that production costs on games are going to be higher on the high-end (XBox360 and PS3, not necessarily the Wii). In the face of this challenge, I would like to recommend that studios do not simply hire more artists. The problem is that production work tends to be uneven. It may take a long time to get a working level because features haven't been implemented, but after features and pipeline are in place the only limiting factors are skill and man-power. In that it may take one person a month to build character or a level.

This may sound like a classical man-month fallicy, but I don't believe it to be the case. As long as the assets are isolated and intercommunication is minimal, then man-months of effort is achieveable. Every level can be isolated from every other level. It isn't like one level is suddenly going to break every other one in the game. It wouldn't be advisable to split off one character to multiple people. But, I do think it is reasonable to get 5 artists all churning out a character in a month once all the pieces are in place. Admitadly, it only works up to a point, but in reasonable scales (4-6 months) I can see contracting upto 20 artists as a workable proposition.

The only reason I advocate this position is because production is uneven. In that very little production work can be done at the beginning of project, but a lot can be done near the end. If the production model is flat, and a ramp-up isn't planned for then an implicit assumption is that production work can be done during the early phases. In my experience, it simply can't. What ends up happening is the schedule says production work is done, when it actually isn't. Near the end of the cycle, when production gets unblocked, there is an unacceptable revisting of previous work which eats into future deliverables. Revisiting and debugging work from months ago, frequently without scheduled time to do so, is very unproductive and a key state that good process seeks to avoid.

My recommendation is to plan for ramp-up. Keep some staff artists whose responsibility is concept and prototype, get the tools solid, then contract the remaining artists near the middle to end of the project, when you have a proven production pipeline. The staff artists primarily responsibility at that point is to instruct and direct the building of the assets and troubleshoot.

I am not saying that it can't go awry, any software project can go awry. However, with production art work there are pieces that need to be put in place inorder to get production quality work done. However, if those pieces are not inplace (or are incomplete) developers find themselves implementing stop-gap solutions to get the artists productive to meet the schedule. But the artists never get productive because all the solutions are stop-gaps, and the developers never get the time to fix deep issues because they are too busy helping the multitudes of artists with the stop-gap solutions they've implemented. Which feeds into the fact that production quality work isn't really getting done.

Plan for a ramp-up, contract the artists in, plan a few weeks of training, assume that 10-25% will not cut the mustard and watch their output like a hawk. I am not stating that this is an ideal scenario, but I think it is better than the alternative scenario and will keep overall production costs down.

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.

Imperial Life in the Emerald City (Inside Iraq's Green Zone) by Rajiv Chandrasekaran is an eye-opening account of failures in immediate aftermath of the Iraq war. The book does not paint a coherent picture of what should have been done to correct the situation. There are always disagreements. Using the advantages of hind-sight, it is easy to say different decisions should have been made. Or if "they" would have listened to a suggestion or addressed this problem, things would have worked out better. That type of nit-picking is natural and in some essences unavoidable. I personally don't believe that it reasonable to expect flawless execution in any new situation. What is expected is to make more correct decisions than bad ones; to improve and make long-term progress.

In that sense, Iraq post-war planning was a failure from the get-go. The defense department's expectations for how post-war Iraq was going to unfold was optimistic. The rampant looting should have been the first indication that this assumption was misguided, but wasn't heeded. The looting set back reconstruction immeasurably, which set unfavorable conditions for the aggressive policies the coalition provisional authority (CPA) would try to pursue. This, in collusion with, having under-qualified people on the ground made the start-up costs particularly staggering. I think we sent intelligent and talented people to Iraq. However, we did not send the most informed, experienced and wise people at our disposal to lead the effort. The administration chose to send the loyal and idealistic. This coupled with bubble environment that was the Green Zone perpetuated the misunderstanding of the reality of the everyday Iraqi and the people working for the CPA.

The first priority should have been to establish pre-war levels of employment, basic services and security. Instead, the CPA pursued an ideological based agenda towards trying to establish a modern representative democracy and a western free-market economy, no doubt influenced by Milton Friedman's ideas that the two go hand-in-hand. The factors of the setbacks in reconstruction due to the looting in conjunction with the fundamental overhauls that the CPA was trying to achieve caused enough chaos to fuel an insurgency. If more pragmatic policies would have been pursued, much of the dissatisfaction would not have come about.

I feel that another misunderstanding is the belief that the insurgency can be defeated militarily. It cannot, although that is one way that it must be fought. The insurgency developed because of high unemployment, degradation of the Iraqi's standard of living, and a continuing sense of social disorder. In order to fight the insurgency, it is necessary to fight its growth and the root causes. The growth can be handled militarily, but the root causes must be addressed politically and making real progress on the ground. I believe that the rise of the civil war we are now faced with is a direct result of trying to establish democracy too quickly without providing a proper social and economic framework for it to flourish. Setting up such a framework is unworkable in the short-term. The immediate problem is that people in Iraq are desperate. Desperate for security, food, water, electricity. These immediate needs will be provided by local warlords who seek to destabilize the existing rule and try to establish their own.

I have always been against the war in Iraq. I consider it to be a mistake of almost comical proportions. But, I subscribe to the viewpoint that is attributed to Colin Powell: you break it, you own it. I considered an Iraq under Saddam Hussein's rule a low threat to the United States. In spite of the fact that he was a "bad man." However, I believe if the United States were to leave now, we will see Iraq turn into an extreme terrorist state. We will be blamed for the ensuing conflict which will likely involve years of fighting and have bouts of ethnic cleansing.

In order to come to an acceptable conclusion to the Iraq conflict, we must establish security, basic services, and employment. All three must be pursued simultaneously or none will be achieved. I don't believe the end result of that effort will necessarily be a moderate democracy. But, we have to leave a stable state, not a govenment on the brink of collapse, ripe with sectarian conflicts ready to erupt.

I don't know if what I suggest is tenable. It is harder to implement than it is to say. And I know that it will probably cost 1000's of American servicemen their lives. However, I believe the threats to our nation caused by another extremist Islamic state fueled by massive oil reserves, and on brink of nuclear capabilities is too great to ignore. I believe Iran will fill the power vacuum that an immediate American withdrawl from Iraq would bring.

I'm not for this war. I wish the US had not started it. But, I believe we have Iraq in at least as stable of a state as it was before we invaded. Anything less will cause Iran and North Korea scale problems in the future.

Today is the day of the Iraqi elections. The question still remains whether or not they have any legitimacy, Iternational election monitors are in Amman, Jordan. The U.N. washed its hands of the whole situation. The Kurds and Shi'ites seem to have no problems voting, but Sunnis in the middle part of Iraq are under a constant threat of violence, reinforced with mortar and rocket attacks along with car suicide bombings.

Iraq is on the road to democracy and this is the latest step. But, I don't know under what criteria you would use to judge this election as a success or failure and what meaning does it have if the canidates themselves are too scared to even admit they are running for fear of assasination. Iraq's citizens are allowed to vote, but on what basis are they making their decision?

One thing is clear, Iraq is a long way from stable democracy. Iraq represents a large investment for America in both monetary costs and human life (not just American but also the Iraqis themselves). I don't know if the American people are fully aware of the huge investment it is. Or how its ultimate success or failure depends on factors that are external to anything America does. The Iraqis are beholden to make democracy work, something they didn't exactly ask for.

So we wait and see, but have no doubt that we were cursed to live in interesting times.

I honestly believe that the American economy is in for some rough times. At the local level, I see a great squeezing of the middle class. We have moved away from a manufacturing economy to a service economy. The reason for this shift is to exploit cheaper labor and more lax environmental standards in developing countries. While this drives down costs for corporations, the cheaper production costs are seldom passed on to consumers.

The displaced manufacturing workers have to find a new job. Since manufacturing jobs are gone, the jobs left open to them are service jobs. These in general don't pay as well, nor do they produce anything that we can export to other countries. This results in massive trade defeceits. But this trend has been going on since the 80's. The question is: why have we been able to sustain this? One reason is that trade defeceit is exagerrated, we have American companies importing goods from their oversea factories. There is a steady outflow of cash to pay the workers. But, the major effect is the rich getting richer in America and the middle class becoming poor. But this doesn't totally explain the phenomenon either, since our oil imports are massive.

The best explaination is the dollar. Foreign countries buy our dollar. Since the dollar is cheap to produce, we are basically getting oil in exchange for paper. Here is another explaination. Although, I don't believe this to be the reason for the Iraq invasion.

So our dollar is inherently valuable, and it also means that we have huge foreign debts that may be cashed. This means, right now, the American economy is inflated by foreign investment. There are certain reasons why I believe this will change. The biggest one being the Euro. The US has alienated much of the world. I believe in retaliation, many contries are going to move their reserved funds to the Euro. This is going to be catastrophic to the US economy. Our dollar will rapidly lose value w.r.t. to other currencies and inflation will rise trying to balance our trade defeceit.

Balancing our trade defeceit is going to be hard because our local economy is now based on services, and secondly, that cheap labor that we were getting in other countries isn't going to be cheap in the face of a devalued dollar. This means a very painful transition.

What needs to happen: most importantly we need to ween ourselves off oil. But, ever since Carter said we had to do it in the 70's our leaders have done nothing to move us off oil. This is unlikely to change under the current political situation.

My best advice is to insulate yourself, I suggest investing outside the US. Invest in gold, Asian or European countries. All we need now is something to trigger this and I think the bubble will burst.

The natural comparison of Bush's vision of a society of ownership society is to say that we are currently a nation of renters.

In local terms, such as myself and my lifestyle I don't understand where this notion of a nation of renters comes from. I don't believe the vast majority of Americans are "renters" in a convential sense. Sure, we rent things. But sometimes it makes sense to rent things rather than own. Renting a car from an airport makes more sense than many alternatives. Renting an apartment makes sense if you are a temporary living situation, such as attending a university. In an ideal world, I still think that there would be some renting.

However, what I think Bush is really getting at, and something that is much more sinister is not the move towards less renting, but rather more ownership. This means, in simple terms, is less public spaces and public land. I don't think it is a wise idea for every section of this country to be owned by one person or entity. It is good and right that we do have public spaces and lands. The US is a nation of tremendous resources, but these resources need to be managed for the public good not for local benefit as any one familiar with the prisoner's dillema will tell you, local best interest is not always the best solution to global prosperity.

But, the scariest move is Social Security reform. In my mind, this is a large and tragic mistake that undermines the purpose of the system. The benefit of social security is that it is always there. It has a lousy rate of return and some reforms are needed, but most reasonable reforms revolve around making sure congress keeps their collective hands out of the "cookie jar" that is Social Security income so-to-speak. Bush's plan undermines social security because what if the stock market crashes? Unlikely, yes. But possible, definitely. Well, anyone with their social security in the stock market just became SOL. But, that was the whole point of the program to begin with, so that people weren't SOL when they retired.

Social security was developed in response to the great depression. Bush is making the susceptible to the same forces that caused the need for its introduction in the first place. How can this be catergorized as anything else other than folly?

I work for EA. I intern'd for Microsoft. As far as my short experience and ongoing experience at the company goes, I my experience working for EA is not as bad as some horror stories on the 'net. Although, the EA spouse thing does bring up my greatest fear about the job, that is, the job will consume my life.

Also, I thank that person for writing that livejournal entry. This needs to be discussed and thanks for bringing it up in a way that everybody at the company and a lot of people that don't have an oppourtunity to discuss. Your post was also extremely well written and you didn't flame the company although it didn't paint it in a good light, which was also good.

However, I can honestly say that working for EA does not consume my life as of yet, although, I have heard that will change once we hit Alpha. I can easily see why we are likely to have a painful Alpha. We are shipping early. Designs aren't done although all of our TDD's (technical design documents/implementation plans) are supposed to be final. The time to do TDD's is compressed becasue designs they are late or unfinished. I had a game designer literally change a design doc while I was working on a task. It wasn't like the TDD wasn't completeless worthless anyway. It was scheduled for a week, and basically said "Do It." But, how are estimates supposed to be accurate if we don't know what we are implementing? Is this the same company that expresses their competitive advantage being they know what game they are making better than their competitors?

Then there are problems from the software engineering point of view. We have no automated testing (besides the test project I just set up). Most code isn't even unit testable because functions change their behavior based on some global game data usually from a half dozen different modules. QA hasn't been doing their job, in that they haven't found obvious bugs in code. I think the only thing that saves us is that it is written in C.

That said, I think the process we have is good. We just need to follow it. This is a lot better than what my experience at Microsoft was like. Developers need to take more ownership over quality because we are the ones that end up paying and QA doesn't do their job very well.

Ultimately, whether I stay at EA for longer than 3 years is totally dependent on my life not being Hell working for them (at least the me leaving part of it). I hope things get better. But, it is more of a matter of being able to light fires under people's asses. Dev's just end up paying the price since they are at the end of the pipeline. It is exactly like expecting a women to produce a baby in under 9 months. It won't be properly developed and the baby is likely to have many problems because there wasn't enough time to do things right.

The head of the studio talked about EA Spouse. So I know they are listening. But, actions speak louder than words. He sort of made light of it, which to me means he was out of touch with the problem. He needs to take it seriously. We lose too many good devs because of this crap. My project has already lost two, which makes it tougher on the rest of us. Then the whole thing just snowballs and things get worse. Which is definitely not good for the company, shareholders, or profits for which he is the steward.

I was reading The Corporation: The Pathological Pursuit of Profit and Power. It is a very insightful book about the most dominant institution of my time.

Before discussing the book in particular, let's be clear on definitions. An institution is organization that compels people on what they can, can't and must do. Government is an institution. Marriage is an institution. The church is an institution. So is the corporation.

The corporation is driven by one metric: profits for share-holders. The case law for this is setup by Dodge vs. Ford. Shareholders can sue managers that do not pursue profits as their top priority.

This doesn't mean that corporations need to go after consumers in an unenlightened fashion. The best way to really exploit someone is to get to know them a little first. Corporations do the same. They are set up to gain our trust in order to exploit us most.

Another fact is that corporations are only concerned with their own costs, not the total. If there are costs that they can get other parties to pay for, they will pass them on, no matter how high and no matter what said party is able to pay. A corporation, by its very nature will do it. In economic theory, these are known as externalities. An externality is a cost occurred on a third-party that was not taken into account by the transaction. Corporations are driven to make all costs external to transactions.

Of course, the only institution that can deal with the corporation is the government. To a large part, the government has been derelict in its duty to protect its citizens from the exploitive aims of corporations. The government's key role in regulating corporations is to make sure they internalize costs that they cause to society. Deregulation is the equivalent of getting rid of the police. Privatization of schools and social security defeat the whole purpose of having those programs. But the key thing to remember is corporations are not concerned with the public good. They are concerned with maximizing profit no matter what they may claim about caring for people.

All this is argued very effectively in the book. But, the two things that I'd like to discuss. The first is the disconnect between managing companies and shareholders. Managers of established blue-chip corporations do not get there on any type of merit. If George W. Bush were not a Bush there is no way he'd be president. It is much the same with other top executives. There is no expectation that Ken Lay of Enron will ever have the financial concern of a hard-working mother in What Cheer, Iowa. Despite his misdeeds, Ken Lay will never be poor in the way people can be in Iowa.

There is an echelon of people for whom there is no merit for their position. We effectively become socialism for the rich, capitalism for the poor. The point is that the drive to pursue profits comes not from Mom and Pop shareholders but rather rich, major stake shareholders who are usually the ones running the company. However a significant percentage comes from the masses, and although there total stock is great in number than maybe any single person owns. The power is dilute and nigh impossible to organize. So managing companies have free reign to pay among themselves, what ever they want, to do what ever they want as long as they don't upset the major stake shareholders.

So, the issue may not be from corporations per-se but the culture from which the major stakeholders arise.

The other thing I'd like to point out is that corporations seek to consolidate themselves but isolate their consumers, employees, and critics. The most important tool they have at their disposal is the media. The media is in a sorry state in America. I'm not talking about the sex and violence on television. I'm talking about the general laziness of the news. This is not a matter of liberal or conservative viewpoints. I'm talking about the news being lazy. Crossfire, Larry King, and O'Reilly factor are the best examples. Pundits through out statistics and arguments, but there is substance. No one follows up on the facts and figures. Viewers are left to take arguments on face value. That isn't news. Viewers are not being informed. We need credibility. Calling on two pundits and have them argue over something is not a news program. There has to be some follow-up. Follow-up is hard, so most news programs move on to a new story or invent stories (like the West-Nile Virus).

The press holds an important place in democracy. It must inform. Even the correct course of action given the available evidence can be the wrong thing to do if the evidence is wrong. The press is responsible for coming up with evidence, and they are surely failing.