Page 75 -

70 E. Norling et al.

simplifications in one’s own code, so there will be in the code of others, and it
is important to understand their implications. Parameters may need adjustment, or
algorithms tweaking, in order for the code to work in a different context. Thus, one
needs to thoroughly understand at the very least the interface to the code and perhaps
also its details. In some cases, the cost of doing this may well outweigh the benefits
of reuse. One of the advantages of an exploratory process is that it tends to educate
the modeller as to the properties of its algorithms in the process. 4
It is important to note that even though the approach presented here deviates
from more formal approaches to software development, this does not mean one
should ignore the standard “good practices” of computer programming. Indeed, due
to the complexity of even the simplest models in this field, it is advisable to do some
planning and design before coding. In particular, the following principles should be
applied:
• Conceptualisation: any model will benefit greatly from developing a clear
understanding of the model structure and processes before starting to program.
This is often called a conceptual model and usually involves some diagramming
technique. Whilst computer scientists will tend to use UML for this purpose, any
graphical notation that you are familiar with will do to sketch the main entities
and their relationships on paper, such as mind maps or flow diagrams. Apart
from helping a modeller to better understand what the model is about, this will
form a valuable part of the overall model documentation. See Alam et al. (2010;
appendix) for an example of using UML class and activity diagrams.
• Modularity: it is not always possible to cleanly separate different functions or
parts of a model, but where it is possible, it is hugely advantageous to separate
these into different modules, classes or functions. In this way, the interactions
with the other parts of your model are limited to what is necessary. It makes it
much easier to test the module in isolation, facilitate diagnostics and make the
code much simpler and easier to read.
• Clear structures/analogies: it is very difficult to understand what code does and
to keep in mind all the relevant details. A clear idea or analogy for each part
of the simulation can help you keep track of the details as well as being a
guide to programming decisions. Such analogies may already be suggested by
the conceptions that the programmer (or others) have of the phenomena under
study, but it is equally important not to assume that these are always right, even
if this was your intention in programming the model.
• Clear benchmarks: if there is a set of reference data, evidence, theory or other
models to which the simulation is supposed to adhere, this can help in the
development of a model, by allowing one to know when the programming has
gone astray or is not working as intended. The clearest benchmark is a set of
observed social phenomena, since each set of observations provides a new set
of data for benchmarking. Similarly, if a part of the model is supposed to extend

4 Sometimes painfully!