Defining Awesome — 2011 — July
  • Status Updates

  • Posts from July 2011

    July 2nd 2011

    Bad code & release dates

    Some requested a definition of good/bad code in the thread below.
    Archont is right with “good code” : works as expected. But I have a slightly different view.
    Suppose you want something expected to work on a release date (can be a major release in 6 months or just a patch in 3 days).

    Good Code:
    Any code that moves you closer to the release date.

    Bad Code:
    Any code that moves you further away from the release date.

    With this we see that if you don’t set a release date you cannot measure how good or bad is your code. So your development time increases infinitely because you might spend time rewriting and “perfecting” code that already works. Of course there are some companies that say it’s done “when it’s done” (like Valve, Id, 3D Realms RIP). I believe they just don’t announce a release date. I’m sure someone disciplined like Carmack sets release dates that are kept even for himself (like setting milestones). There is a paragraph in “Master’s of Doom” where it’s noted that Carmack after releasing Quake locked himself for a week in a hotel room to experiment with some technology. Doing that sets a deadline of 7 days. After that you expect to have something awesome working. It doesn’t matter what is inside the source code or how it looks.

    My favorite release date approach is a deadline of 1 day. When I start work on that day I say to myself: today I will make a physics engine or today I will make a particle engine. I work only on that during that day and usually at the end I have something working. Code made this way is usually the best code I make. If I tweak it or add stuff later it usually makes the code worse and less elegant. Doing a big chunk of code in 24 hours makes you remember the whole thing in your head. So you work the whole code in your head. The next day you will forget most parts of the code. If you return in a couple weeks there is nothing left of your understanding of the code. In 1 day it is possible to understand every bit of the code.

    Try it, instead of working on every piece of the game from time to time. Just take one segment of the game and try to code it in 1 day. If you fail, erases it, and try again.