I completely agree. This is the biggest issue with a programmer becoming an indie game developer (as opposed to project managers, QA or artists). I find the best solution to this problem is to wear a different hat on different days. Spend one day with a programmer hat on, coding (in C# of course ) and another day with project management hat on managing schedules and generally organizing the project.

I’ll check out “outliers”, it sounds like an interesting read. I would completely agree that good enough is often enough to make a successful product.

A programmer’s world consists of

if (a) then (b) else (c);

But who knows if the game that you are writing is going to be a hit? People are unpredictable.

There’s a good book called “outliers” that examines successful products, people and ideas and tries to work out why they were successful. It’s main thrust is that in spite of what you’d think, these things often don’t need to be brilliant. They just needs to be “good enough”. Good enough means that they are above a certain threshold. All the rest is about being in the right place at the right time. Which isn’t easy to code, (even if you try to do it in c# rather than c++. )

You are quite right that the development of the game is only part of the solution. Marketing and business are a vital part of creating a successful game. I’ll look at writing some entries on this in the near future, thanks for the suggestion.

Why? They followed a lot of the guidelines above and when you are small, you tend to take less risks, have more focus on what you need to achieve and know you can’t simply go around problems by throwing money and resources at it. Cross-skilling is also a great plus in small teams.

On a side note, we used to use FogBugz where I currently work up until about a year ago when we switched to TFS. It’s good for a small project that doesn’t rely too heavily on issue and bug tracking but beyond that I wouldn’t recommend it.