Tuesday, January 20, 2009

ASSERT() does not fix crashes

Windwos BSoD

A problem has been detected because coders always say, "this should never happen".

The problem seems to be caused by the use of: ASSERT()

#define ASSERT(x) assert(x)
#define ASSERT(x)

If this is the first time you have this stop error screen, restart your computer. If this screen appears again follow these steps:

Check to make sure you've bullet proof the code. If this is a new application, ask your fellow coders why you are stupid to only use asserts instead of writing the code to gracefully handle the error condition.

If problems continue, also check for other piss poor lines of code giving lazy programmers a bad name. If you need to use a Safe Mode like try{}, throw() and catch(), you're an idiot. The end user doesn't care about your error codes. Restart your computer and DEL all of your files because crashes aren't useful.

Tech information:

*** STOP: 0x00000050 (0xDEADBEEF, 0x0000001, 0xBAADF00D, 0x00000000)

*** ASSERT() - Address 1F0CED17 base at F0C17F0C, DateStamp 80fca82

first a few articles to get my point across. the following are error messages made by microsoft engineers.
Best Windows Error Ever May Rip Time-Space Continuum, Destroy Reality
Dec 6 2007

Windows Vista Error?
Jun 3 2007
and i'm pretty sure everyone on the planet (who's a nerd) has seen this great PR shot:
Blue Screen of Death Strikes Bird's Nest During Opening Ceremonies Torch Lighting
Aug 11 2008
first, a sad program just pooped out. the second one a funny accidental icon enumeration selection. and that last BSod could have been a microsoft bug. but then again, maybe not.

with what it is essentially equivalent to a kernel panic -- it pretty much rests on the lowest level of the OS where everyone can point and laugh at the main player. not the application or program.

was it a driver? or the video playback program? who else is responsible for these?
when people start to make fun of spectacular crashes on a giant projector, it's hard to remember that it's sometimes the idealistic coder that broke the application and that windows had nothing to do with it. take the following articles:
Microsoft Arcade Fail
Jan 18 2009

We Interrupt This Program With a Windows Error
Jan 1 2009

Jesus Tries to Save Your Soul But Windows Stops Him
Aug 28 2008
that isn't to say that microsoft should be absolved from all of their own problems. patch tuesdays, red ring of death and zunes freezing at new years to name a few examples.
Cause of ZUNE leapyear problem - Freescale date routine
Dec 31, 2008
now, what basically happened here was that a coder probably had a brain fart and just didn't think through of all of the permutations. it happens to every coder.
this is when i was reminded of the absolute absent mindedness of using ASSERTS();

normally, asserts and exception conditions are pretty useful for developers to announce (NOT TEST FOR) those "this should never happen" situations. to this day, i still see coders do something equivalent to the following:
my_data_block = get_some_piece_of_data();

ASSERT( my_data_block, "data block is empty" );

for those who do not know what the assert() function normally does, is this:
test the first parameter and see if it is valid.
if it is OK, continue on with the next line.
if it is NOT valid, halt the program here.
sometimes, coders will have a second parameter to "provide more information" on what just happened. and sometimes, these ASSERTs are macros that get compiled out during a RELEASE build (versus a DEBUG build). in other words, they are "scrubbed out" of the code automatically when making a version of the application/program for public deployment.

here's why i can't believe people still code just like the example above. if my_data_block did not receive a valid chunk, the program will continue (in a public release build) and crash when we try to do_something_with_it... this is when you'll see one of those error message box.
like i said before, the end user doesn't really care about (let alone know what to do with) your error codes or exception messages you happen to catch. you should NEVER code like that. here's one example to code it properly:
my_data_block = get_some_piece_of_data();

ASSERT( my_data_block, "data block is empty" );

if ( my_data_block )
// instead of terminating the application
// all of the sudden
there are other ways to do this. but essentially, you need to make sure your code will not just die on you. any time you see an application freeze or see an error message box -- it's the mark of a n00b coder.

if you see your CPU usage spike outta control - then the coder is mediocre. something got locked in an infinite loop. these are sometimes a surprise to find. but that's when testing will make you a good coder. (yes, i still see people submitting stuff in with out testing their work. we normally call them artists. but once in a while, coders do this too.)

what's an expert coder, you ask? that's someone who stopped reading this article right after my little BSoD sample at the top of this article.

courtesy of XKCD

the only time you should terminate a process is a user supplied add-on/plug-in. keep your application running. i'm always surprised to find piles of CRAP javascript code, but am extremely impressed that web browsers will ignore malformed code. too bad not all applications are designed like this.

time and time again, i see high end applications that costs $#!t loads of $ $ $ such as Maya and 3DStudio Max -- crash. the artist constantly complaining, stOOpid editor... when i am willing to bet 95% of the crash is because of a plug-in "one of our" coder wrote to extend the exporter, importer, utility, attach-this, or do-whatever to the 3D editor. if those "scripts" were validated as well as the results they generate - i bet applications would seem much more "stable" to the end users even when shotty (or absent-mindedness) programming are applied to them.

yeah, there'll be a trade off in speed - but if it comes down to the stability of the application - this is something that might need to be considered. otherwise, it's pretty much planned, "let's ruin the user's experience..."

PLEASE DO NOTE: to the independent / individual / or just starting off developer(s); i completely understand that there is a difference with a handful versus a team of 10, 20 or 100 people that might be physically impossible to code every possibility and know all the permutations with little time (or encounter the occasional brain fart). but if your project is a rockin, and you get piles of people to work on it - please take out the "temporary" assert reminders (or use an alternative "messaging" mechanism), keep your application running and put in actual functions to gracefully handle those unfortunate cases.

Monday, January 5, 2009

the Rape of Midway Games

a long time ago, in a city far far away (at least from where i'm at right now), the Chief Monkey Officers sought to bleed as much money as they can from the company before high tailing it out of town to escape the destruction they left behind in the wake of:

i have come to the realization that douche nozzles with MBAs (and marketing veeps) who goes into a company who knows nothing about that industry - only takes the job to make out like a bandit not caring about all the peons who work there.

Work Work Work

Me Not That Kind of Orc
and anyone who plays RTS games knows that you can't do $#!t with out the humble peon worker. (images courtesy of battle.net)

note: i started writing this article dec 1st, so this article may sound a bit dated. also, i thought against publishing this since it didn't seem nice to comment on the people who used to be with my former employer (i left more than a year ago -- the writing was on the wall -- and it wasn't hard to see this coming. i gave the company 5 years left instead of just one). anyways, in light of the following articles, it was time to add my 2 cents:
Midway execs get rich while company crashes
joystiq.com - Dec 23rd 2008

Midway Execs Raked In Big Bucks While Company Foundered
ign.com - Dec 23, 2008

let's take a look back at Midway Games when the sith began to take control of the senate.
David F. Zucker Named Midway's Chief Executive Officer and President
may 07 2003

Midway Games Acquires "Area 51" Developer Inevitable for $2.1 Million
October 11, 2004

Midway Games Acquires "Mortal Kombat" Developer Paradox Development
November 30, 2004

Midway Games Acquires Aussie Developer Ratbag for $5.6 Million
August 4, 2005

Midway Games Acquires U.K.-Based Pitbull Syndicate for $3.1 Million
October 4, 2005
more than $11 million so far (ongoing salaries and the cost for paradox, etc.). but first, in light of this whole financial market disaster the whole world is currently in, a snapshot of Midway's stock at the time Mr. Zucker started to the day he filed his fire sale [businessweek.com].

MWY - Midway Games historical price
March 07, 2003 to December 09 2005
a healthy 662.67% gain. nice.
(chart from Google Finance)

this is where it dawned on me, that everyone in the financial sector are also only there to take your money. more on this a little later.

continuing, there was businessweek.com interview "Sumner Redstone, Video-Game Whiz" that has a few juicy tidbits.
...the media mogul,... sat down and explained why he's such a fan of the video-game industry -- even though he has never played such a game [ Mortal Kombat ] himself.

"this company [ Midway Games ]-- which was hardly known a year ago..."

"I don't have any information that is not public. I have told David to never give me any material inside information."

on Paramount making an Area 51 movie:
"I have absented myself completely. [Because Redstone also owns a 70% stake in Viacom, he has recused himself from Viacom discussions concerning Midway to avoid conflicts of interest. ...]
redstone has absolutely no idea what it takes to make a video game. he was someone who had a big bag of money, looking for a project to see if he can get into the video game market. the chiefs smelt blood. here's where the raping begins.
Midway Games to Sell $75 Million in Convertible Notes
May 24, 2006

Video Game Publisher Midway Faces Investor Lawsuits
July 23, 2007

Midway Games CEO David Zucker Resigns
March 20, 2008

Redstone Sells Majority Stake in Midway Games
December 1, 2008
MWY - Midway Games historical price
December 09 2005 to March 31 2008
(chart from Google Finance)
note: this chart does not include the 2008 global market meltdown numbers - only to the day zucker has resigned (almost an 88% drop)

how can redstone keep tabs on a company, that was "hardly known a year ago" (NFL blitz, NBA jam, ... mortal kombat... whatever...), let alone take a no hands approach to running the company is beyond me. he hires some guy who also knows nothing about making video games, and basically "talks the company up, just to drive it into the ground". the guy also plays the moronic "increase market share by buying your smaller competitors" bull $#!t rule.

a whole bunch of peons in the studio were perplexed at the decisions to buy studios (all over the world) only to shut them down in a matter of months (and no, no technology was ever gained from buying these studios - a sequel or 1 was sometimes done... and that's it...). and instead of reappropriating resources on projects that clearly didn't show progressive results, more money was poured into sinking boat anchors. wtf.
image courtesy of ibdeditorials.com

as for the cash infusion, there was no rhyme or reason for it at the time (other than to take more money from these "investors"). did redstone benefit from the convertible notes sales to cover his enormous loses? probably not. but i don't think the company burned through all of that cash on day to day expenses either.

zucker has managed to leave the company with a lower stock value and a humongous debt. the day before he was hired, midway was trading at $3.57 (and at around $8million in debt at the end of 2002). and on the day he left: $2.01 (and a $250million debt).

the following should be in a separate article (since it's getting a little long already - but i don't want to revisit this in a future article).

back to the money people. these dirty wh*res would lie, cheat and basically steal the money that should have been given to the people who are actual making the products. i don't know what were they thinking when they basically cut all of the bonus/royalty numbers, adjusting the payout program or renege on reserves (scheduled retention bonuses) and expect the developers to stick around.

it got so bad that there was a major meeting with the team and the finance department to explain their actions. no answers were ever given to the peon workers. the money monkeys would constantly repeat "the payout equations are complicated". i would love to see who can tell me the answer first, the finance department to rotate a point around a line in 3D space or if the coders can figure out how "complex" the royalty equations really are.

i was going to go on and on about how a bunch of brand new cars (M5's M3's and other 5series vehicles) all of these execs suddenly showed up literally on the following monday right after the theft-fest meeting - all in all, the peons got the shaft.

anyways, what's left of Midway Games right now? everyone who has nothing to do with video games are gone. that's finally a good thing. but, a lot of people i knew are also no longer there. and the ones who are still there... can finally enjoy their down time after crunching for this winter's holiday season releases (maybe permanently, too). it was pretty interesting seeing how many linked-in profile updates were fired up right after this meltdown.

it sucks that matt booty got left in the path of destruction with more than a quarter billion dollar debt to figure out. but i trust him more than any of the other "CEOh-nos" to run a video game company. an actual game developer with experience. but i would actually recommend to leave this disaster and start a brand new studio. leave the legacy of the old studio to the former board of directors and past CEOs. there is no away to keep this studio running anymore except to sell off the assets and IP for the new "owner". basically, a reset like atari did is needed.

i would like to leave this post with a pretty interesting interview with Eugene Jarvis who made a lot of arcade games that many of you may have dropped hojillion quarters in.
The Making of…NARC
edge-online.com - September 16, 2008
“The company was screwed up, like their worst competitor had staffed the upper management. The guys they hired could not have done a better job of destroying everything. A guy with no knowledge about videogames says: ‘What’s wrong with this company is we need more schedules and managers’.”