<$BlogRSDUrl$>

Thursday, September 15, 2005

Orphaned Content is NOT the Problem here...

Hot Coffee has had some unintended consequences in the real world. In my "Daily Planet" job, I'm a software developer. Not for anything cool, you understand. Just business stuff. We recieved an update to an industry publication about "coding best practices", and it now suggests that orphaning code is no longer the preferred method for dealing with late feature cuts.

Let me translate that from suit-geek to normal human. These guys publish a bunch of suggestions as to how people should do their work if they're doing it right. They even include their opinions on technical stuff like coding. Suits who don't know how to actually do the work really dig this stuff because they think that it gives them some handle on the situation. Used to be, if you had to make a big change to a product near shipping, it was a good idea to just make it so nothing would talk to the offending code rather than cut it out and possibly make more bugs to have to chase down. Now they say that's a bad idea. This is where the whole "Hot Coffee" thing comes from - it was originally a feature they cut because it didn't get into the schedule until late and it would have killed their rating so they just cut it off and left it in there. That used to be a good thing, but now it's a bad thing.

If you look under the hood and into the code of any large software package you're going to find stuff that you're not supposed to be able to see. There are times when you're writing software that you have stuff in there you later determine you don't want. Usually it's a feature you don't have time to properly implement, or some unforseen issue or external event that you have to adjust to. For example, there was a minor kerfubble with PhotoDraw 2.0 and calling it "v2" in England that freaked out some WWII vets and necessitated some quick changes right before release. There are times when removing something will cause bugs in other places in the software and it can be very difficult to test for these and fix them. It has been a standard practice for years that when you are at that point you leave the unwanted code in, but make certain that it can't be accessed. There's probably code like this under many M rated games that was orphaned to keep the M rating rather than go AO. That late in the coding process there is no way any responsible developer would pull the code - it's just too risky and they're accountable to the publishing company for the cost of it and the schedule over-run. No malice. They're not trying to trick you. Just a very common compromise that has to be made between the schedule and the deliverables.

It isn't just games. I made a choice like this myself at 1:30 this morning to keep a bug in code that had been tested out otherwise sound. It was "orphaned" by not dropping the file that allows people to see it via the brower. Instead of having the page opening taking out the entire application, everything else worked swimmingly unless you clicked on this one thing and then it just gave them a 404 error. It sat there that way until about an hour ago when I figured out exactly what weird thing was going on in it's raincoat and fixed it. Of course, Murphy showed up and did his thing. Someone did notice it. A customer got shirty, and I got yelled at. I wasn't exactly enchanted but it was nothing like I would have had to listen to had they spent the morning dealing with the side effects of me just yanking the thing willy-nilly at that unholy cow-milking hour of the morning and leaving it throwing hard errors until I could get it fixed. Luckily, there were no naked people involved.

This whole thing begs a question for me. If we're having a problem with orphaned content in there that might offend someone, what about all the other things that are in the code? Say one of the developers swears in the comments of the code in a game, or there's a localization issue that makes part of the code a swear word. You think I made that up, but I didn't. I've seen it myself in a Nintendo game. A mis-translation of the FUNC call made it come out F*CK. The F-word all over the place. That's been fixed long ago but it's still out there on some older carts. No one should ever see it, though. You have to reverse engineer the game and that is not a trivial matter.

So does that mean your child shouldn't be playing the E-rated and squeaky clean Super Mario Bros. or Kirby's Air Ride? Well, if you've got a six year old who knows how to crack a cart or reverse engineer a GameCube disk and has the equipment to do it then I say that kid should be coding his own games and I know some people who would like to talk to you. But how many kids is that? Why did someone buy the kid the hardware and who taught them how to do that? And if that kid did do that and see those swear words, is it Nintendo's fault that he's seeing it?

I'm not saying this should be used for every feature pulled. The developer needs to use their head for something besides a hat rack. Anyone who can read the FAQ at ESRB.com should have known damned skippy well that the content in Hot Coffee was never going to make it past them in that form. And they should have known it well before the point in the schedule that would have made cutting it off like that necessary. They made a bad choice and they got bit in the you-guessed-it for it.

But responding to it by biting everyone in the arse isn't going to fix the core problem. Not allowing developers to use orphaning as a way of minimizing bugs is foolhardy. That means that in a game or software product with a tight development schedule if they decide not to implement a feature or change their minds about the way things work then they have no recourse but a full-on regression run with it's costs and risks. For console games, that could mean another run through the hardware company's Certification process. For a PC game, that means another trip through whatever verification provider you use and those cost.

If the gaming industry and the business software industry start using those best practices we got handed, then the new best practice will translate into slipped schedules, buggier releases and missed launch dates. And that's not "best" for anyone.