Code testing: what I learned from watching Notch code
The theme music for this post is The White Stripes – A Ball and A Biscuit.
Warning: This post may smack of fanboyism. Can’t be helped.
During last weekend’s ‘Ludum Dare’ competition, famed Minecraft author Notch screencast his entire development process for almost all of the time he was coding (which, by the way, was a very impressive 40 of the 48 total hours the competition lasted!) I spent a good deal of time watching, and this is what I’ve learned. I should disclose that I’m not a professional game developer, though I am an amateur game developer and I am a professional software developer.
The Nitty Gritty
I could write a lot about all the little code tricks that he uses, like making his levels in Paint.NET or the way the lighting works in his cool 2.5D engine, but instead I’m going to write about the process, as this is where I learned the most. For those interested the technical stuff, the source code of his game, Prelude of the Chambered, is available online here at his Ludum Dare page. There are lots of gems in there.
The most important thing I learned was his testing technique. Notch tests continuously, and he tests completely thoroughly, playing through the entire game every time he makes a change.
Incredibly Fast Testing
He began by building the engine, and to do this he used the ‘HotSwap’ functionality of the Java JVM 1.4.2, which continuously updates the running code when it detects that a class has changed.
When building the engine, Notch wrote a function which would continuously pan the camera around and clip through the walls and keep the view on top, so he could make changes to the code and see the effects they made in real time. I’m used to testing by writing a function, building it, installing it on the device I’m testing on, and then seeing the result, which can take up to a minute at a time, so it’s easy to see how HotSwapping could save a lot of development time.
If anybody at Google is reading this, if you add this feature to the Android emulator and I will literally drive to your house and kiss you on the mouth.
Incredibly Thorough Testing
How I Use This Knowledge
I’ve tried to incorporate this process into my own development style. As I’m primarily a web and mobile developer, this typically means creating a new user account every time I make a change to the project.
Normally I have a quick-and-dirty, get-shit-done type of development style, so I do find this very tedious and frustrating. However, it has been very beneficial for me for two reasons.
First, it forces me to pay attention to the support systems of a project earlier in the development cycle. This means things like the email server for notifications, database migrations and stuff like that – the stuff I normally hate doing, but the stuff that quietly matters the most. The upside of this is that I get a lot of peace of mind knowing that I don’t have to do all that stuff later.
The second benefit is the obvious one: the user experience improves drastically. By forcing myself to register an account every time I make a change, I very quickly realize which aspects of the project need streamlining, which aspects cause hangups to registration and engagement with the site, and how to improve navigation and interaction within the project.
Here’s the TL;DR: Notch tests constantly and he tests completely. Doing this is a pain in the ass, but it exposes more bugs and makes a better user experience. Also, celebrity coders doing screencasts is an awesome idea, and I hope to see that trend continue.
What do you think of this style? Is this just something everybody does that I only just realized? Or is this a unique quality which has made Notch such a successful programmer? Leave a comment below!
Interested in working with Gun.io? We specialize in helping engineers hire (and get hired by) the best minds in software development.