Page 67 -

62 E. Norling et al.

5.1 Introduction: Exploration and Consolidation Modelling
Phases

Formal approaches to the development of computer programs have emerged through
the collective experience of computer scientists (and other programmers) over the
past half-century. The experience has shown that complex computer programs
are very difficult to understand: once past a certain point, unless they are very
careful, programmers lose control over the programs they build. Beyond a certain
stage of development, although we may understand each part—each micro-step—
completely, we can lose our understanding of the program as a whole; the effects of
the interactions between the parts of a program are unpredictable; they are emergent.
Thus, computer science puts a big emphasis on techniques that aim to ensure that
the program does what it is intended to do as far as possible. However, even with
the most careful methodology, it is recognised that a large chunk of time will have
to be spent debugging the program—we all know that a program cannot be relied on
until it has been tested and fixed repeatedly.
However, it is fair to say that most computational modellers do not follow such
procedures and methodologies all the time (although since people don’t readily
admit to how messy their implementation process actually is, we cannot know
this, just as one does not know how messy people’s homes are when there are no
visitors). There are many reasons for this. Obviously, those who are not computer
scientists may simply not know these techniques (in which case they should at least
read Chap. 6 in this volume). Then there are a large number of modellers who
know of these techniques (to some degree) but judge that they are not necessary
or not worth the effort. Such a judgement may or may not be correct. Certainly it
is the case that people tend to underestimate the complexity of programming and
so think they can get away with not bothering with a more careful specification
and analysis stage. In some of these cases, the modeller may regret not engaging in
more planning, but there may also be other times when there are good reasons not to
follow such techniques. Thirdly, a specification and design approach is simply not
possible if you don’t have a clear idea of your goal. Often, when modelling some
complex phenomena (and especially social phenomena), one simply does not know
beforehand which parts of the system will turn out to be important to the outcomes
and which can be safely omitted. Further, one may not even know what will be
possible to model computationally.
One of the big benefits of modelling phenomena computationally is that one
learns a lot about what is crucial and possible in the process of building a simulation
model. This is very unlike the case where one has a functional goal or specification
for a program that can be analysed into sub-goals and processes, etc. In (social)
simulation, the degree to which formal approaches are useful depends somewhat on
the goal of modelling. If the goal is very specific, for example, understanding the
effect of the recovery rate on the change in the number of infections in an epidemic,
and the basic model structure is known, then what is left is largely an engineering
challenge. However, if the goal is general understanding of a particular process,
then there is no possible way of systematically determining what the model should