on Jun 2, 2011
Here is a question from reader cody:
Me and my brother got into an argument recently and I figured you could help us settle it. It started when an update for Minecraft was released that caused the game to crash when shift clicking items into a full inventory. He thought this was incompetent coding on behalf of the developers and that any problem like that would be obvious and easy to fix. I told him that it’s a lot more subtle than that and any number of seemingly insignificant bits of code could break the game in major ways. In the end we both agreed that computers only do exactly what you tell them to, our opinions on what that means are different though. He thinks that it means if you tell them to do something that breaks the game you’re bad at making games.
There’s an old saying among writers: Writing is re-writing. The real work isn’t having an idea or putting the words down, the real work is when you’re done with that and you have to go back and polish, cut, and expand until the work flows.
There’s a parallel saying for software engineers: Programming is debugging. Yes, a terrible programmer will write bad code. But a normal programmer and an exceptional programmer will write good code. The difference between the two appears when it comes time to locate an obscure bug or intuit the source of a problem based on the non-technical ramblings of an end user. A task like that can take a day or five minutes, and it all comes down to how deeply the programmer understands the discipline.
The thing is, ALL programmers write bugs. John Carmack is one of the most brilliant software engineers alive today. He’s a visionary, an inventor, a member of Mensa and yes, he’s also a rocket scientist. Yet he writes bugs just like the rest of us. It’s unavoidable. Saying a programmer should never make bugs is like saying writers should never make typos. A good one will make fewer than a bad one, but they happen to everyone. (In fact, it’s probably pretty even between great coders and average coders, because we all seek our own level. If you’re able to write something completely bug-free, then you’re under-utilizing your abilities and you’re probably bored at your job. We all want to hit that sweet spot where the work is challenging enough to be interesting and rewarding, but still easy enough to avoid frustration.)
But this Minecraft bug isn’t about programming skill. That’s a playtesting problem. Writing the bug was a trivial mistake. Releasing the bug was less so. This began as a one-man hobby project with low expectations and is now a multi-million dollar project with a team and an immense base of customers with the usual consumer demands. Mojang is going to go through some growing pains as they develop a production pipeline and company policy regarding releases.
Having said that, let’s keep this in perspective. As I said on Twitter a few days ago:
Today’s Minecraft beta was SO BUGGY that I nearly thought it was a post-release AAA game from Bethesda!
I’m not usually an apologist for companies who put out buggy software, but the game is in beta. This was one bug, released during beta testing and patched soon after. If this is the wost sin of Mojang, then they are way, way ahead of just about every other studio on the planet.
As for how such a simple thing could lead to a crash? Pfft. There’s a thousand things that could to that. Here’s a hypothetical:
The feature is: When you open a container and shift-click on an item in your inventory, it transfers the whole stack into the container for you. If you click on something in the container, the whole stack is moved back to inventory.
But of course, some containers are joined with other ones, making double-sized containers. Additionally, these joined containers must act as one, so that clicking on either one will present the same list of items in the same order. (As opposed to listing the one you clicked on first, followed by the “other” one, which would confuse users, since it would look like items were “re-arranged” in their box.) If one container is full, your shift-click should send the items into the second container. Containers are joined in pairs, and these pairs can be formed by any two adjacent cubes on the same vertical plane.
If the logic for this was messed up, then it can end up trying to put items into a container that doesn’t exist. Boom. Welcome to crash city.
Maybe Notch wrote the feature, built a single box, tried it, and concluded it was done, without testing it on double boxes. Maybe it worked fine at first, but later making changes to how the server and client transfer container data resulted in a shift-click causing a crash.
Note: This is not an informed guess. Or even a wild guess. This is an illustrative example to show that the complexity of a feature has nothing to do with how simple it is to USE.
Notch single-handedly wrote a rendering engine, an interface, a character animation system, and a client-server architecture. No, he’s not a bad programmer.