Well, I said I was going to write more frequently, so I thought I'd get in the habit of it. Maybe quality of posts is more important than quantity. Ah well, we'll try this out and see how it goes.
It sure is alot harder for me to get motivated to write code outside of work these days. I guess programming all day is enough to make anyone want to do anything but with their spare time. It seems like it should be easier to work on my own ideas. Maybe if I were more organized; I think the problem is I'm not sure _how_ to get organized.
I'm working on the same thing I've been working on for years. I want to get a killer code base together so I can work on some games. There are a few things that have come to light while working on my own project, all things that are true with any project, but especially so when you have a small team (like one guy, for instance) The main purpose of posting this here is so I don't forget to consider these things when I start on revision two. I've been reading up on some of my favorite software development blogs lately to see what I'm doing wrong (Joel on Software, anyone), so forgive me if I blatantly rip off someone else's quotes or something.
- Know your feature set, and don't stray from them (feature creep)
This seems like a no brainer, but when you want your project to be the
best of the best its easy to get carried away. For example, the current
project I've got going is in it's simplest form a game engine. The
problem is, there aren't any parameters for the project laid out so
when I started programming I wanted to have a 2D game engine for
Windows. Simple, right? Well, a few months later the project was turned
into a 3D general purpose game engine with cross-platform support but
still able to support features from the latest and greatest of graphics
hardware. Now that's a pretty tall order, especially for one guy
working on it in his spare time with no professional game development
experience to go off of.
- Design Twice, Code Once
Ok, I stole this saying from carpentry, and tweaked it a little to fit
into programming, but there are plenty of similarities that make this
adage hold true for software development as well. It's a whole lot
easier to see weak points in your design if you get all your ideas out
on paper first, and it's nearly impossible to change code once its
released, especially if you've got other parties using your code.
Nevermind that without design upfront you'll more than likely run into
a show-stopping road block at some point in your development process.
They made us write design documents in school for a reason.
- Keep your specifications reasonable, and set deadlines
I tend to daydream a bit when I start on a new project. Thinking of all
the great, wonderful... no... fantastic features I'll add to my awesome
game engine and how incredible the games will be that use the
technology. The problem is that I'm only one guy, and on top of that I
can only work on this project in my spare time. Start with a core set
of features and get those solid first. You can always add more in
version 2.0. Setting deadlines seems sort of silly on a one man team,
especially when you need to extend those deadlines you only have to
convince yourself. I don't know about you, but I work better under
deadlines. It gives me an idea how hard I should be concentrating on a
given task and most importantly, it helps track progress throughout the
project. Checking off milestones can be a huge morale boost on a solo
team, when there's no one there to tell you things are looking great.
- Use the same tools the pros use
If your a small team working on a project for fun, there's no reason
you can't be using the same tools that the guys getting paid are using,
especially if you're already using them at your paid job. Get yourself
some source control at least. Trust me, it's worth the trouble of
setting up and using, even if you're the only guy on the project. I've
been using Subversion for awhile now on my personal projects and it
really helps, and there's no worry of my files getting out of sync when
I move between machines because everything is stored in one master
repository. Unit Testing and Bug Tracking; also additional tools that
you can add to your arsenal for no additional cost other than a bit of
time it takes to learn, which you will make back over the course of
your project.
Like I said before, these notes are for my own benefit for later projects so hopefully I don't make the same mistakes twice. By making it public maybe someone out there can glean a bit of experience from my mistakes. There are of course exceptions to these rules, and I obviously didn't hit every important point in a software development cycle. If anyone thinks of other things to note or corrections to the rules, please discuss. If I were an expert at this, I wouldn't have to write it in the first place so please feel free.