Learning from mistakes

Posted by Gavin Bowman on Tuesday, March 18, 2008 at 2:00 PM

Learning from past mistakes always makes a good topic, and the series running on Bruce on Games is no exception. Bruce is sharing some of the disasters he experienced while working at Codemasters. Even if you have no direct interest in the games industry, you can find some good general lessons and anecdotes here.

The first post was about Club Football, an attempt to take on the mighty FIFA and PES, by building upon an existing engine from a management game. The USP was that there was a different product for each major team. Here are some of the general software business lessons I picked up on.

Forced Productization of a module: We've probably all looked at a script, or a tool, or a small chunk of our software, and started to think there could be another product there. It's always tempting, and it probably works out sometimes, but it's always worth checking your enthusiasm. In any successful product, the coding is only part of the battle, and even if half of the code is already written, it's always harder than it looks to actually finish it. To be fair, based on the comments on Bruce's post, this may not have happened in the Club Football case.

Lack of clear target market: 17 different editions, 17 different markets, 17 different budgets... clearly this isn't something a Micro ISV would attempt, but it's worth bearing in mind when considering a few different versions or target markets for a product.

Choice of USP: Read Bob's ebook :).

The second post is about Dragon Empires, an MMORPG that never made it. The development began with a small team updating an existing product, but as time went by the team and the budget kept growing. In the end it consumed years and millions. The dominant concept seems to be money, both lack of and too much (or more generally, the control of resources).

This made me think about things like when to buy components or tools (when being too cheap often ends up costing you), and about managing a development scope, making sure you have a clear release target and stay focused on that track (when not being cheap at all ends up costing you). Make the first mistake in your Micro ISV and you end up spending a year re-inventing numerous wheels, or trying to carve a rose with a chainsaw. If you make the second mistake, you end up spending many years building some bizarre evolution of your original idea, and you'll be lucky if you ever release anything.

[I used the word "cheap" to mean "keeping a tight eye on resources", both financial and otherwise... I've never been embarrassed to be cheap when necessary, but if that word has too many negative connotations for you, substitute frugal, prudent, economical, disciplined... whatever you like...]

Great stuff anyway, I'm looking forward to the rest of the series.

Tags:

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home