Page 76 -

5 Informal Approaches to Developing Simulation Models 71

another model, then restricting the new model should produce the same outcomes
as the original. 5
• Self-documentation: if one is continuously programming a simulation that is not
very complex, then one might be able to recall what each chunk of code does.
However, when developing this type of simulation, it is common to spend large
chunks of time focusing on one area of a model before returning to another.
After such a lapse, one will not necessarily remember the details of the revisited
code, but making the code clear and self-documenting will facilitate it. This sort
of documentation does not necessarily have to be full documentation but could
include using sensible long variable and module names; adding small comments
for particularly tricky parts of the code; keeping each module, class, function
or method fairly simple with an obvious purpose; and having some system for
structuring your code.
• Building in error checking: errors are inevitable in computer code. Even the best
programmer can inadvertently introduce errors to his or her code. Some of these
will be obvious but some might be subtle, difficult to isolate and time-consuming
to eliminate. Detecting such errors as early as possible is thus very helpful and
can save a lot of time. Including safeguards within your code that automatically
detect as many of these errors as possible might seem an unnecessary overhead,
but in the long run can be a huge benefit. Thus, you might add extra code to
check that all objects that should exist at a certain time do in fact exist or
that a message from one object to another is not empty or that a variable that
should only take values within a certain range does stay within this range. This is
especially important in an exploratory development, where one might develop a
section of code for a particular purpose, which then comes to be used for another
purpose. In other words, the computational context of a method or module has
altered.
These matters are covered in Chap. 6 in this volume in greater depth. There
are also many techniques that computer scientists may exhort you to use that are
not necessarily useful that may be more applicable to the development of software
with more clearly defined goals. Thus, do evaluate any such suggested techniques
critically and with a large dose of common sense.

5.5 Understanding the Model

Understanding a model is so intertwined with controlling a model that it is difficult
to cleanly separate the two. You cannot really control a complex model if you do not
at least partially understand it. Conversely, you cannot deeply understand a model

5
What the “same outcomes” here means depends on how close one can expect the restricted new
model to adhere to the original, for example, it might be the same but with different pseudorandom
number generators.