This diagram emphasises the importance of measurement in the optimisation process: you cannot begin the process, evaluate your optimisations, even discard your optimistations or honestly finish the process without first measuring the program performance versus your target performance.  As I have mentioned before the initial optimisations to a program tend to yeild larger returns and then returns drop off until much more time is invested. These initial easy optimisations are not usually the sort of changes new programmers expect: they expect sexy l33t code like inline assembler for big performance wins, not tweaking compiler flags or removing calls to a pure virtual method on a base object in an inner loop.

The bottom half of the cake consists of the languages with low levels of abstraction, with microcode at the bottom and C++ at the top, all of these languages are compiled languages which means their source code is interpreted and compiled into a lower level language e.g, C++ is compiled into assembler.  I categorise C++as a lower level language for the purposes of this diagram as its memory management is still a manual process unlike the languages in the layers above it, which makes it less trivial to use.

Microcode is the lowest level of abstraction available and it is the programming language used to create assembly language instructions.  Assembly Language is the language used by computer processors (CPUs) and is specific to each CPU family and is also the lowest level at which software can typically interact with the CPU.  Next is the common low level languages C and C++ which I’ve bundled into the same layer as C++ can compile C code so they are not really completely distinct.  Although C++ is a higher level language than C as it supports object oriented programming which is typically considered a feature of high level languages.

The top half of the cake can be roughly split in to two groups of programming languages: those languages that are compiled (blue box) into a lower level language before execution by a compiler and those that are interpreted (green box) at run time by an specific interpreter program. The bottom half of the green and blue boxes represent the respective compilers and interpreters for the languages.  It is worth noting that although the .net programming languages (C#, CLR C++ and VB.net) and the Java family of languages are all compiled, they are compiled into byte code executables before they can be executed (run) by a virtual machine (usually written in C/C++).  The interpreted languages Ruby, php and Python are not compiled before execution but are interpreted at run time by an interpreter program (again usually written in C/C++).  Interestingly interpreters do exist to process Ruby (JRuby & IronRuby) and Python (JPython & IronPython) source code into byte code for the Java virtual machine or .net CLI, allowing ruby or python to be run on any Java or .net CLI virtual machine.

Compiled languages like Java or .net must be recompiled before they can run on a different virtual machine however this is usually not a serious issue as .net and Java virtual machines exist for most opereating systems in some form or another.  Recompilation is not a requirement for interperated lanagues which only require a functioning intererator on the target operating system to be able to be run, which makes them easier to use across multiple operating systems and leds to them being considered more portable than the compiled languages.

The initial phase of a project is ‘Pre Production’ where the main game concepts and features are brainstormed, designed, prototyped and signed off on.  The end goal of this phase is to prove (usually via a demo) the core game play experience and produce a feature brief, technical designs and a development schedule.  The project team is usually lightly staffed until ‘Production’ begins.  Next comes the main development phase ‘Production’, this is usually the longest phase in a project and is where the games features and content are created and put together.  The ‘Production’ phase is usually broken into several parts separated by milestones with pre-set deliverables according to the development schedule.

After production comes the main bug fixing portions of the cycle, although ideally bug fixing should be a continuous activity during the whole cycle.  ‘Alpha’ is usually defined as the phase when all game features have been implemented but the game still contains major bugs like crash bugs and the game play still needs tweaking.  Next is ‘Beta’ usually defined as features complete with no major or crash bugs, ‘Beta’ is usually restricted to minor tweaking of the game.

Post ‘Beta’ all that is left to do is ship the product, traditionally this meant sending a disc (usually gold coloured CD-R) of the title to the publisher for duplication for retail.  This is where the term ‘going Gold’ comes from.  During the ‘Gold’ phase of development any changes are forbidden except bug fixes requested by the publisher.

The final phase of a project is post production, during this phase the whole development team is not usually present as people take holidays or are assigned to other projects.  The main focus during ‘Post Production’ is that of clean up and refactoring of the code base, pipelines and game systems.  This includes analysing the development cycle, usually in the form of ‘Post-mortem’ style reviews and brainstorm sessions with the focus to improve future development efforts based on recent experience.

Mapping user expertise against the user population of a product tends to result in a bell shaped curve.  Indicating that most of the user population for a piece of software has an intermediate level of expertise.  This is an important observation when developing software as developers (as expert users themselves) will tend to develop more expert features and customer support will push for more beginner features.  There is then a high probability that the largest part of the user population (the intermediate users) will be ignored, at the cost of increased product adoption or sales.

It is generally regarded that there are three primary properties of a software product: cost of development, performance (speed/memory etc) and software quality.  It is believed that you can only ever obtain two of these properties at the cost of the remaining property e.g, you can have high performance and high quality but it won’t be cheap to develop.

My experiences over the years tends to confirm this rule of thumb but I can’t help wondering if that fictional high performance, high quality and low development cost software has ever been made?

This may seem strange but in my experience it is true that the first few optimisation efforts on any un-optimised system tend to yeild high returns for low effort e.g, tweaking some compiler or linker settings in a few minutes.  Further medium term efforts tend to suffer from diminishing returns e.g, rewriting critical sections in assembler over a few days for a few percent improvment.  Finally large scale optimisations e.g. refactoring entire sub-systems over a week or more tends to yeild significant benefits.

As the above graph demonstrates, there is a practical limit on team size before the communications load required to keep team members in synchronisation begins to significantly reduce individual team members performance.  The usual method for combating this trend is to partition large teams up into smaller teams to reduce the communication overhead per individual.

Source ‘Agile Software Development’ by Alistair Cockburn page 160.

This at least is how it always feels: a mystical 10% of the code base causing 90% of the reported bugs.  This makes it very important to identify the 10% of the code that is causing the bugs and then resolve those issues as a matter of priority.  Wasting effort on the other 90% of the code base until the problem 10% is resolved will not make a noticible improvement in the product quality.