Deficit programming

Here's a synchronicity, I've recently been experiencing some major bug problems with my game, due to fast and sloppy programming. I was trying last night to come up with a good phrase to describe the phenomenon when I came across this post on Shamus Young's site.

Basically deficit programming is when you trade time for code robustness, you get code written quickly, but it isn't particularly well put together. This can lead to numerous bugs and strange behaviors in the future, especially when you try to expand on it.

The past couple of weeks I've been adding a lot of features to my game, and not taking the time to do it carefully the way it should be done. I felt (and still do) that it was justified because a lot of the features I was adding weren't going to stick around for very long.

As you're working on the gameplay elements of a game, you have only a vague idea how things are going to affect each other. This is something I had heard about, but didn't really understand until I saw it first hand. Introducing a seemingly small element can drastically alter the way things work. With this kind of thing going on I didn't want to spend five or six hours adding a feature the right way, only to rip it out when it didn't work from a gameplay perspective. If I could get it in in two hours, and see how it works, well that was very tempting.

So right now I've got a good accumulation of elements, but I've also got a good accumulation of bugs that I'm trying to work through. In any case, it was really encouraging to be reminded that I'm not the only one who goes through these kinds of problems, this post was also very helpful in that regard.

Thanks Shamus.