During the course of developing Equals we have spent a lot of time thinking about what we are developing, developing test code, and then re-writing final code that ends up getting implemented in the project as appropriate. We also have a large backlog of previously written code to work from, although a lot of the prototypes are in Objective-C for iOS which we can’t use on the web. The good news is we have learned from all of our previous mistakes.

The benefit to all this throw-away code, something we have never really had before, is that the final code is a lot more solid. Rick and I are both noticing that we aren’t hacking in a lot of code to just make things work. That’s been a facet of almost every project we have done in the past ten years, which is partly a bi-product of having near-zero experience on the platform we are working on and always being in a ridiculous hurry.

With Equals that has been less of an issue. As we fix bugs now it is clear that the logic was correct. The changes are inserting a line here or correcting a mistake there, but not having to either rototill code or hack in fixes for stuff we have. It feels more stable.

This hasn’t just been because of the previous code we’d written, of course. Another big benefit is that we took far more time than ever before to plan and document what we were doing. An insane number of hours, for instance, went into figuring out how the server-client API should work. Even stuff like how do we determine what’s a variable and what’s an equation was hours of planning and thought. I had a college professor say that 70% of development should be planning. This is one of the first times in my career where I was near that number.

None of this is to say we won’t look back at this code in a year as garbage. But at least we know in a year that this code will be highly supportable garbage.