Quality Over Time And Money

I wish this would be this simple – as usually we need to cut corners to get the game finished (I have this feeling every day when I’m thinking about adding features or doing something that is meant to increase the quality). Basically there’s a production triangle which has three corners: time, money and quality. We can measure what type of project was in terms of quality, time and money.

Here are some examples:

  • Adding quality (for example: making better gameplay) might mean that game production requires more time (and could mean need for more money).
  • Adding time means that we have more time to increase quality, but it also might require more money (for salaries or similar).
  • Adding money could mean that we can increase quality (as some developers could use better tools or use more time to make something). Adding money can reduce or increase the overall time of the project depending how money is spent. If money is spent to hire 2 artists instead of 1 then the overall time can be reduced, but if money is spent simply to let programmer finish some feature properly, then the overall time might increase.

After the project is completed we can see if some of the corners “leaked” (like perhaps time was spent more than initially thought, or perhaps quality level was not what we wanted or maybe we spent less money than budgeted). While it’s sometimes very hard, I like to focus on quality over time and money as the rule of thumb. Sometimes it’s darn hard, but that’s my suggestion. I think it’s okay to take shortcuts and get rid of useless features, but the overall quality is number one corner in my books. If the game is not a quality game – then it won’t be worth publishing.

Juuso Hietalahti


  1. Yes, it’s true that if you don’t have enough time or resources, the outcome won’t be good no matter what.

    From what I’ve read the XP people’s (Kent Beck or Scott Ambler, don’t rmember which book it was from, sorry) gripe with the production triangle is that it doesn’t take account things like difference between people and methods. For example, if your product is bad because of some fundamental flaws of your software process, it won’t automatically help if you throw more people (especially those previously inexperienced with that product) people into that mess.

    So basically the gripe is that the triangle oversimplifies a lot. And the XP people tend to value good working conditions and experienced/skilled people a whole lot more than is usual for the “old-school” project management genre that the triangle represents (at least in the stuff I’ve read, sorry, but still no actual quote).

    I’ll have those books back in couple of weeks, if this topic is still valid then, maybe I’ll come back with a quote ;)

  2. I think the XP methodologies and agile programming contains much useful concepts on how to work. I think there’s plenty of useful things and everybody can pick the parts seem good for their work. I’m trying to stay away from any XP versus something else wars, and I don’t really know if XP enthusiasts criticize production triangle.

    Production triangle sort of covers XP style – you cannot continue doing XP if you run out of money. If you have one week time to do fun game, no amount of unit testing can guarantee that fun. I don’t see how this fit in the whole picture, as I kind of look this from the perspective where project has limited amount of money, time and the outcome is supposed to have certain quality. How you achieve that quality (whether it’s XP or whatever) is different question – in my opinion. But I would gladly look at some example.

  3. How do you feel about “them XP enthusiasts” that criticize the production triangle? One example of that is that if you use test-driven development, you don’t use up any more time or resources than if you wouldn’t and still end up with higher quality product because of the extensive unit testing made during the development?

Comments are closed.