Page 73 -

68 E. Norling et al.

5.4 Maintaining Control of the Model Whilst Exploring

The second biggest problem in following the exploration and consolidation
approach to model building (after that of giving in to the temptation to promote
your results without consolidation) is that one loses control of the model whilst
exploring, resulting in a tangle of bugs. Exploration is an essential step, testing
the impact of the assumptions that have been made but, if not carefully managed,
can result in code that achieves nothing at all. Bugs can creep in, to an extent that
fixing one merely reveals another, or the model can become so brittle that any
further modifications are impossible to integrate, or the model becomes so flaky
that it keeps breaking in unexpected ways. Although interactions between processes
might be interesting and the point of exploration, too much unknown interaction
can just make the model unusable. Thus, it is important to keep as many aspects as
possible under control as you explore, so you are left with something that you can
consolidate! It is generally helpful to be clear (if this possible) about which aspects
one is certain about and which aspects one is exploring. If these are separable, then
one can apply the techniques in Chap. 6 of this volume to the parts one knows and
constrain the area of uncertainty where the exploration is occurring.
The main technique for maintaining control of a model is doing some planning
ahead and consolidation as you explore. This is a very natural way for a modeller
to work—mixing stages of exploration and consolidation as they feel necessary and
as matches their ambitions for the model. Each programmer will have a different
balance between these styles of work. Some will consolidate immediately after each
bit of development or exploration; some will do a lot of exploration, pushing the
model to its limits and then reconstruct a large part of the model in a careful and
planned way. Some will completely separate the two stages, doing some exploration,
and then completely rebuild their ideas in a formal planned way but now having a
better idea (if they are correct) of what they are aiming to achieve: what needs to
go into the model (and what not), what is happening in the model as it runs and
which results they need to collect from it. It is a general rule that more checking and
consolidation will be required than is generally planned for by modellers. 2
There is no absolute rule for how careful and planned one should be in developing
a model, but roughly the more complex and ambitious, the more careful one should
be. Whilst a “quick and dirty” implementation may be sufficient for a simple model,
for others it is unlikely to get the desired results: it is too easy to lose understanding
and control of the interactions between various parts, and also the model loses the
flexibility to be adapted as needed later on. At the other end of the spectrum, one
can spend ages planning and checking a model, building in the maximum flexibility
and modularity, only to find that the model does not give any useful results. This
might be a valuable experience for the programmer but does not produce interesting
knowledge about the target phenomenon. This is the fundamental reason why

2 Even when you take this principle into account!