In college I was driven to learn and make the most of the experience. It became common to start a project Friday night only to never touch it again after that Saturday or Sunday. This was great practice, but each projects became a nightmare to manage. Nearly all of them fell to the underdarks to collect dust, never to be built or ran again. Recently, however, I’ve been able to let a project sit on the side for six months and pick it back up like I worked on it yesterday.
Managing personal projects like this has come down to a few habits that I have enforced upon myself with the last two years. The first is writing high-quality code. That is, code that is easy to read and easy to maintain. Next, always use source control and never drop a project while it is in a broken state or in the middle of a large refactoring.
Those short projects in college were great to focus on a particular algorithm, technique or technology. Even my college classes geared me toward this, sort of, quantity driven mentality. This was mildly beneficial as the game industry is, pretty much entirely, quantity driven. More and more features, less and less time cause us developers to throw in the 5 minute patch to make something work. I have since learned this is entirely the wrong way to go about game development.
A few years ago, I had the opportunity to go to my technical director and say, “With all these new features added to the menu, the code is getting a little cluttered, it might be time to refactor.†and have the response be, “Yes of course, go for it.† This is so far off from the rest of my experiences, it is unheard of.  That project pegged how important code quality is and, since that time, I’ve focused my efforts toward code quality, not quantity.
During my quest of higher quality code, which is never ending, I’ve set out to create my personal coding standards. I bought a book on coding standards, read a lot of material on the internets and started that document as a standard for personal and, if allowed, professional projects to come. Part of this standard is to use source control on any project with an expected life span of more than two days, or has more than a single person. I use SVN, but other systems like Git work just as well.
The trick is to never set a project to the side unless it is in a working state. If a project is unbuildable, crashes upon entering the main menu, or in the middle of a refactoring, it is unlikely to be continued once it actually collects dust. By leaving the codebase in a working state, and writing high-quality, readable and maintainable, code, you set yourself up for a project that will have a much longer lifetime, but don’t take my word for it – try it yourself.