Last time, we looked at the number two cause of production delays, next to procrastination: premature coding. As there always seems to be when it comes to software design, there is a third prong to this set of release delays. And a fourth, and a fifth, and…
The third one is called Cool Stuff Syndrome. You could swap that second word out for another word beginning with S, but I’m not allowed to because I’m writing for a family-rating. Let’s just call it “CSS,” and remember that we’re not talking about web design.
CSS is, in a nutshell, what happens when a coder is working on their current part of the software, and says “You know what, it would be really neat if this feature I just thought of at this very moment was in the game. In fact, it would be so neat, that I’m going to drop everything just to work on it.”
Sounds ridiculous, right? Unfortunately, this happens in almost every project. At least one coder will get a bright idea, and sacrifice everything else just to get it in the game, under the radar of management. Here’s what happens:
Day n (1 for convenience): On schedule. Coder thinks of a neat idea, and instinctively starts writing the code for it in his/her (his for convenience) head, as coders often do. He thinks to himself “it won’t take more than a few hours to put this in, I’ll just do it and it’ll be cool.”
Day 2: 1 day behind schedule. The code took a little longer to implement than he originally thought it would, but it’s coming along nicely. One more day, and it should all be done, and he’ll be able to get back to the stuff he’s supposed to be doing.
Day 3: 2 days behind schedule. The feature is in, and it looks kind of cool. Now he can just work a little faster for the rest of the week to get back on schedule. Good thing he took that course in fast coding last year.
Day 10: On schedule. Everything seems to be going fine.
Day 50: Some catastrophic failure has crept in to the system, and nobody knows where it is. This problem is stopping core features from working, and has completely halted development. Coding cannot continue until this issue is resolved.
Day 60: After two weeks of crawling the code looking for the problem, it turns out to be the cool feature our hero added. It must now be either corrected, which will take an entire day, or removed, which will take about an hour. Because the feature is so cool, he spends a day correcting it.
Day 61: The entire coding department is now two weeks behind. Development continues as usual.
Release day (RD for convenience): Because this column takes place in a perfect world where everything happens right, somehow the game is released on time. Odds are this involved sacrificing valuable testing time, causing an inferior product to be released.
RD +1: Because this column takes place in the pits of Hell where everything that can go wrong does, the cool feature causes a fatal imbalance in the game that must be patched.
RD +5: The first of what will be many patches is released for this cool feature. This patch in turn unbalances several other parts of the game, necessitating more patches.
RD +30: After a month of difficult coding, the problem is finally resolved. Hundreds of thousands of dollars in subscription fees have been lost, and the coder has been fired. The reputation of the company is damaged, and potential future losses from people who got a bad first impression numbers in the millions of dollars.
This may seem like an extreme case, but it is actually the norm when some coder succumbs to CSS. What seems like a simple change often has a catastrophic impact on the rest of the game, because the game is so much larger than the feature that such an impact literally cannot be helped. Just look at all the patches we’ve seen for Diablo 2…
Here’s a very simple example of how a seemingly trivial change can get well out of hand. Let’s say you want to do something as minor as increasing the length of a given sword by one inch. This change has now unbalanced the sword, because it’s suddenly longer than it was when the weapons were originally designed; someone using this sword now has a longer reach than s/he did before. Now the rest of the weapons need to be re-evaluated to make sure the balance between them remains the same. Subsequently, the armours may need to be updated too, to ensure they’re balanced with the changes to the weapons. Then the character stats must be checked to make sure the characters can still use those items when they’re supposed to, and it’s not entirely unlikely for this to necessitate rewriting significant parts of the game’s code, all because of one measly little inch.
The problem is that no one programmer will ever have the entire design document, which makes safely adding or removing pieces of the game impossible; your change will always have an impact you can’t foresee. The only programmer who will ever have the entire document is the head of the Programming department, and if he’s doing this then you have more serious problems than a rogue programmer. Here’s another, more concrete example I encountered recently while upgrading a website I run:
I wanted to add a way for the site’s member base to make suggestions on how to improve the site, because it’s in a constant state of upgrade. I added the suggestion page, and a table to the database. Then I added the admin page to see the requests, and in order to keep track of them properly I had to change the database table while there was live data in it. This required changing the code in the suggestion page, because the table looked different than it did when that page was created.
If I’d not realized I had to change the suggestion page, I would have written and tested the admin page and then left, and the suggestion page would have been non-functional. This is exactly what I’m talking about when I say adding one feature can break other parts of the project. In something more obfuscated than a webpage, the problem might go unnoticed for months, even years, right through to release, and then when it’s finally uncovered by a user the results can be abominable, and much more far-reaching than one page not working properly.
What we need is some way to review a proposed change before it’s implemented; some kind of protocol. We’ll talk about this next time.
Disclaimer: Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.