Page 74 -

5 Informal Approaches to Developing Simulation Models 69

exploration is so important: because one does not know which model to build
before it is tried. This is particularly so for models that have emergent effects (like
many of the ones discussed in this volume) and also for those where there is no
benchmark (either formal or observed) against which to check them.
One important thing about the activity of modelling is that one has to be willing to
throw a lot of model versions away. Exploratory modelling is an inherently difficult
activity; most of the models built will either be the wrong structure or just not helpful
with regard to the phenomena we seek to understand. Further, the modelling is
constrained in many ways: in the time available for developing and checking them,
in the amount of computational resources they require, in the evidence available to
validate the model, in the necessary compromises that must be made when making
a model and in the need to understand (at least to some extent) the models we make.
Thus, the mark of a good modeller is that he or she throws away a lot of models
and only publishes the results of a small fraction of those he or she builds. There
is a temptation to laziness, to trying to “fix” a model that is basically not right and
thus save a lot of time, but in reality this often only wastes time. This relates to
the modelling spectacles mentioned above: one becomes wedded to the structure
one is developing, and it takes a mental effort to start afresh. However, if it is to
be effective, a corollary of an exploratory approach is being highly selective about
what one accepts—junking a lot of models is an inevitable consequence of this. If
one is not following a more formal, planning approach, and one is not throwing a
lot of versions away, then you are probably instituting poor modelling decisions into
your code.
Whatever balance you choose between exploration and consolidation, it is
probably useful to always pause before implementing any key algorithm or structure
in your model, thinking a little ahead to what might be the best way. This is an
ingrained habit for experienced programmers but may take more effort for the
beginner. The beginner may not know of different ways of approaching a particular
bit of programming and so may need to do some research. This is why developing
some knowledge of common algorithms and data structures is a good idea. There is
a growing body of work on documenting programming “patterns”—which seek to
describe programming solutions at a slightly general level—which can be helpful,
although none of these pattern catalogues have yet been written specifically with
models of social complexity in mind (but see Grimm et al. 2005 for examples from
ecology). Increasingly too researchers within this field are making their code, or at
least descriptions of the algorithms used, available to wider audiences.
There are dangers of using someone else’s code or algorithm though. There is
the danger of assuming that one understands an algorithm, relying on someone
3
else’s description of it. It is almost inconceivable that there will not be some
unforeseen results of applying even a well-known algorithm in some contexts. When
it comes to reusing code, the risk is even higher. Just as there are assumptions and

3
Of course, this danger is also there for one’s own programming: it is more likely, but far from
certain, that you understand some code you have implemented or played with.