Brittleness and - IA de Investigación especializada en el MIT

Brittleness and
Bureaucracy: Software as
a Material for Science

Matt Spencer
Universidad de Oxford

Through examining a case study of a major ﬂuids modelling code, this paper
charts two key properties of software as a material for building models.
Scientiﬁc software development is characterized by piecemeal growth, and as
a code expands, it begins to manifest frustrating properties that provide an
important axis of motivation in the laboratory. The ﬁrst such feature is a
tendency towards brittleness. The second is an accumulation of supporting tech-
nologies that sometimes cause scientists to express a frustration with the
bureaucracy of highly regulated working practices. Both these features are
important conditions for the pursuit of research through simulation.

Introducción

1.
Computer simulations play a key role in many domains of contemporary
ciencia. The question of how they transform science has received a lot of
scholarly attention. Many have concentrated on outlining the epistemo-
logical similarities and differences between simulation and experiment
and theory (for example Ostrom 1988; Keller 2003; Winsberg 2009)
and on the diversity of kinds of modelling and representing found across
domains of science (Morrison 1999; Giere 2004). A third direction, cual
I explore here, looks instead at how working with computers, y trabajando
in software environments in particular, gives this kind of computational
science research its distinctive character. Following Knuuttila (2005b; 2011),
I take modelling to be practical engagement, in which software serves as
the material for building and running simulations.

Telling the story of Fluidity, a ﬁnite-element code for simulating ﬂuid
dinámica, as it grew from a small project to a large software system, I show
how piecemeal growth exerts pressures on research through a tendency

This research was supported by the UK Arts and Humanities Research Council.

Perspectives on Science 2015, volumen. 23, No. 4
©2015 by The Massachusetts Institute of Technology

doi:10.1162/POSC_a_00184

466

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

467

towards software brittleness. The trouble that brittleness entails provided
a key axis of motivation for the scientists as the software grew. In an at-
tempt to deﬁnitively push the group beyond these difﬁculties, the Fluidity
developers eventually rewrote the code, and adopted a number of new
technologies and working practices to bolster their defenses against the
re-emergence of such problems in the future. While countering brittleness,
sin embargo, these steps themselves transformed the working environment, y
placed new demands on research time that altered the nature of research,
which some saw as a bureaucratic burden. This is a singular story, but these
transformations of the nature of research can be expected to reﬂect the con-
tours of the wider landscape of computational science, most importantly,
allowing us to grasp the differences between small and large-scale code
desarrollo, and the dynamics of transition between the two.

The case study of Fluidity is based on an 18 month period of ethnographic
observation and extensive interviews with the members of the Applied
Modelling and Computation Group (AMCG) at Imperial College in London.

2. Workability in Research
What makes a good model? A normative question like this has two kinds
of answers. The ﬁrst has gained a lot of attention. A good model is some-
thing that plays a role in inference. Usually this means it is a good repre-
sentation: a computer model, Por ejemplo, that generates data with a good
level of ﬁt with some comparison data set (Oreskes et al. 1994; Kleindorfer
et al. 1998; Lahsen 2005; Bailer-Jones 2003). This then provides grounds
for inferences about the thing represented, or for inferences about the
reliability of the model when simulating systems or problems for which
no such comparison data set exists.

A second kind of answer puts the question of representation on one side,
and regards a model in terms of interactivity, how it affords more or less efﬁ-
cacious manipulative possibilities to scientists. Tarja Knuuttila has pushed for
an appreciation of a model as something that may be judged in its own right, como
what she calls an “epistemic artefact” (Knuuttila 2005a; Knuuttila 2011). A
model is a certain kind of thing, with its own characteristic constraints and
affordances, interactive possibilities it offers to an embodied user (Knuuttila
2011; Gibson 1986). Moving from the subjective meditation of abstract
thinking, to what Gaston Bachelard called the “objective meditation” that
occurs between the researcher and their equipment (1984, p.171), this view
of modelling calls our attention to the material properties of models.

Questions of materiality have been raised by philosophers seeking to
understand scientiﬁc inferences, focusing, Por ejemplo, on the way arguments
may reference the physicality of computational processes that occur when
code is run (parker 2009), or on comparisons with “same stuff” arguments

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

468

Brittleness and Bureaucracy

about material causes found in other kinds of modelling (Guala 2002).
Knuuttila’s departure from this tradition lies in the emphasis on modelling
as something that happens prior to the formalization of arguments.

The practical dimensions of software have yet to be extensively studied,
probably because their concreteness is not as easily appreciated as that of
more intuitively physical models (Por ejemplo, Justi & Gilbert 2003).
Por eso, many studies of simulation regard computational research to be
abstract, symbolic work (Heymann 2006; Sundberg 2008, p.17). Cómo-
alguna vez, citing Klein’s work on “paper tools” (2002), Knuuttila stresses that
“even in the case of symbols and diagrams, the fact that they are materially
embodied as written signs on a paper accounts partly for their manipula-
bility” (2011, p.269; see also Goody 1986; Netz 2003). “Without mate-
riality,” she claims, “mediation is empty” (2005b, p.1267).

Taking up this theme, Mary Morgan has recently highlighted the
“workability” of productive models (morgan 2012). If we look at code in
the making, we can ask how software becomes efﬁcacious as material for
thought and action, a medium for exploration and inspiration. We can also
ask how, conversely, workability may threaten to break down and compro-
mise research. While scientists are motivated by epistemic goals, those I
encountered during my ﬁeldwork were equally motivated by the need to
respond to these kinds of threats, to shore up their research systems against
them and to make them as efﬁcacious as possible for the future.

An initial clariﬁcation is necessary to point us in the right direction.
When I ﬁrst arrived at AMCG to conduct my study of computer model-
ling, I regarded Fluidity as a model. That was how it was casually talked
acerca de, as a versatile model of ﬂuids. I soon realized that this is subtly mis-
leading. If we are interested in the medium of their research, that medium
is not a singular model, but a modelling environment. “I think of Fluidity
as a code or modelling framework, that is not itself a model,” explained
NK, a senior scientist. The code can be set up in limitless ways, con un
vast array of options, coupled models, sub-models. The concept of a model
too easily implies that it is a representation, that it entails a directional
relation with some represented target, what Suarez calls “representational
force” (2010). A modelling framework, por otro lado, has no neat
relationality. It is a software toolkit, a working environment within which
models may be created. Workability is therefore not simply a property of a
modelo, but of a constellation of coupled and integrated software systems
that embodies a potentiality for creating models, a medium in which any
scientist sets up their simulations through the use of existing code, el
integration of new code, and through tweaking and reﬁning the many
controls on the system, some according to explicit rules, but many more
according to the tacit “feel for the game” inculcated by an experienced user

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

469

(Bourdieu 1977). While Knuuttila has pointed the way with her concept
of “epistemic artefact,” the image this provides is too discrete and singular
to account for the workability of software modelling frameworks, cual
exist more as settings, or contexts, para investigación.

3. Piecemeal Growth and Agility
Fluidity, like much scientiﬁc software, is continually evolving, y esto
perpetual change is an index of ongoing investments of effort and interest
by scientists pushing their research in new directions, requiring new or
tweaked functionality from the code, or using existing components for
new purposes. The piecemeal growth that characterizes this software is a
consequence of the manner in which science is funded. It is rare to get
funding to build a large software system from scratch. These systems
become large through a history of additions and extensions. dentro del
terms of individually funded research projects it is usually only feasible
to build a small software system, tailored to the speciﬁc goals of that
proyecto. Once built, sin embargo, it can serve as a platform or a proof of con-
cept for further projects, which extend it in new directions, adding new
functionalities, exploring new possibilities, eventually leading towards
funding for increasingly ambitious extensions. Success in producing results
thus tends to “grow” scientiﬁc software (Basili et al. 2008, p.29).

It has been noted that the piecemeal growth of scientiﬁc software aligns
its development style with the “agile” approaches popular in some areas of
commercial software development (Easterbrook and Johns 2009). Mientras
conventional development strategies rely on comprehensive prior speci-
ﬁcation of the functionalities of the completed product, the signatories
to the “Agile Manifesto” promoted a style which characterizes software
as something that is open and changing, made in a context of changing
requirements (Beck et al. 2001). During a project, the client’s priorities
may change, the market for the product might change, competitors may
bring out rival products; it is not, in many cases, easy to see at the begin-
ning what the product will need to be, so agile approaches focus on
embracing changing requirements. Además, success for a software
product tends to lead to further modiﬁcation, to bring in new features
and keep it up to date with other systems (Matsumoto 2007, p.478).

An emphasis on keeping software projects agile leads to character-
izations of the merits of source code that resonate with ideas of the “work-
ability” of models. With his concept of “habitability,” Richard P. Gabriel,
Por ejemplo, challenges the conventional mode of judging software as a
ﬁnished product. “Software needs to be habitable,” he says, “because it
always has to change. Software is subject to unpredictable events: Require-
ments change because the marketplace changes, competitors change, partes

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

470

Brittleness and Bureaucracy

of the design are shown to be wrong by experience, people learn to use the
software in ways not anticipated” (Gabriel 1996, p.13). This trend in
thinking has drawn attention to source code as an environment within
which developers work, something that was previously often hidden behind
teleologies of ﬁnal products or end user experience. “Habitability makes a
place livable, like home. And this is what we want in software—that
developers feel at home, can place their hands on any item without having
to think deeply about where it is” (Gabriel 1996, p.11). While it implies no
speciﬁcally epistemic goal, habitability nevertheless captures the core of
workability, a baseline of manipulability without which epistemic projects
would be hard to realize, a technical condition that operates in interaction
with the epistemic (Rheinberger 1997, p.32).

No comprehensive speciﬁcation exists for what exactly it is that Fluidity
should end up being. This is common in computational science (Segal and
morris 2008, p.18). Computational scientists are agile workers because
their goals are bound up in the development process, rather than in an
eventual destination. The research projects at AMCG use simulations built
en route with an evolving code (Sundberg 2008, p.5). Studies of scientiﬁc
practice have emphasized the under determination of what it is that scien-
tists aim at (Rheinberger 1997), and it is notable that one of the pioneers
of the agile approach later discovered in Andrew Pickering’s writings
many of the same themes that inspired him to push for new strategies
in software development (Marick 2008). If the researcher knows exactly
what they are aiming at, it is hardly an inspiring topic for research (ver
Polanyi 1983). Similarmente, where speciﬁcations dominate software cultures,
it is hard to see the creative side of development practice (Evens 2006). So
Fluidity develops according to a meandering, iterative logic, being put to
many uses for many different kinds of studies, each which stresses and
extends it in new directions. No singular idea exists for where it is going.
One senior member of the group told me that the goal was eventually to
make it “a whole earth model.” Another said that they were aiming at an
ultimate “toolkit” for making simulations. A third regarded the software
as secondary to the community of expertise they were building through its
development and use. All these perspectives feed into the management of
Fluidity, but none with the determining character of a ﬁnal cause.

4. Fluidity’s Early Life
Fluidity began its life in the late 1980s as part of a Ph.D. project looking
at small scale ﬂuid phenomena for industrial applications. The original
author, CK, brought his code to Imperial College a few years later when
he joined the Applied Modelling group, which at that time was primarily
concerned with studying radiation transport problems for nuclear reactor

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

471

engineering. Fluidity was soon integrated into the toolkit of the group,
because this opened the door to studying nuclear applications involving
ﬂuids, such as those found in ﬁssile solution reactors. With the assistance
of a new coupling code, “FETCH,” Fluidity was coupled to “EVENT,"
which was the main AMCG nuclear modelling code.

This emerging interest in ﬂuids within AMCG sparked much further
development of Fluidity and in the late 1990s new staff was brought on
board to extend the code to new applications such as multiphase ﬂow
(where ﬂuids transition between liquid and gas phases) and to render it
capable of running efﬁciently on highly parallel supercomputer architec-
turas. En este punto, AMCG was composed of 15 científicos, and was roughly
evenly divided in its work between radiation problems and ﬂuids problems.
In the early 2000s, sin embargo, a major new funding initiative began which
doubled the size of the group within four years and rapidly accelerated
the pace of development of the code. The main part of this project was a
major extension of Fluidity from its previous incarnation as an engineering
código, to a huge new realm of geophysical applications, from oceans, coasts
and rivers to atmospheric and mantle physics.

Fluids became the largest area of study within AMCG, and by 2010,
there were around 30 scientists actively developing Fluidity. The engineer-
ing and small-scale computational ﬂuid dynamics research continued, mientras
geophysical applications accounted for more than half of what this much
bigger development team was studying. The beginnings of this expansion
in 2001–2003 saw the commencement of many new geophysical research
projects, but it also saw a major shift in the way that the science was done
because the expansion of the code had led to threats to its workability.

The expansion of the group was an expansion in the number of people
involved, but this also brought with it an expansion in the number of dif-
ferent agendas for which Fluidity was being used. The group experienced
new demands for collaboration and communication. Al mismo tiempo, el
increase in scale resulted in an increased rate of change for the Fluidity
code base. The software was being changed often, by many people working
on many different projects. These stresses placed a burden on the team that
was exacerbated by the fact that much of the code had not been written
with an expectation of future massive expansion. The priority during the
early life of Fluidity had always been to deliver the short-term aims of
speciﬁc research projects, and there had been little time or money available
to make the system maximally extensible. Además, as is the case for
many computational science teams, the majority of scientists working on
Fluidity had not come from a computer science background. They were
predominantly mathematicians, engineers and physical scientists. Incluso
now, few PhD students coming to AMCG have worked on complex

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

472

Brittleness and Bureaucracy

software systems before they arrived. They learn on the job and as KU
pointed out, this has good and bad effects: “when you have a team of good
programmers around you you learn by osmosis. But when you have a team
of bad programmers around you learn by osmosis as well!” When Fluidity
was a small/medium sized enterprise, there was a degree of tolerance for
idiosyncratic working practices. What mattered was getting good simula-
ciones, and the quality of software was less of an issue. But as it grew, este
tolerance dwindled.

As a mathematician I was never interested in coding practices. Él
didn’t bother me. As long as my code ran fast and did what it was
supposed to do I was happy. So my codes were often a tremendous
mess. Someone like WS would have been none too happy seeing that.
But then that is no problem when you are on your own—no-one else
has to look at it!" (SOY)
Over the years Fluidity had been adapted … bit by bit for different
applications. We ended up with quite an unmanageable mess, qué
coders call “the code becomes brittle.” There were so many hidden
assumptions in the code that as soon as you change one detail the
whole thing breaks down (HP).

The trouble with the code in the early days of the expansion was ex-
pressed in very tangible terms. The code had become “brittle.” This term
is a commonplace within software cultures. Brittle code is the opposite of
robust code (it is important not to confuse the robustness of code with the
alternative use of the term as a measure of agreement between the outputs
of different models—see Parker 2011). Brittle code breaks more often than
robust code. But the fundamental problem with brittle code is not so
much that it breaks more often—all code can be expected to break when
being developed – it is that when it does break it is hard to ﬁgure out
exactly why. Entonces, when you have ﬁgured out why it broke, it is hard
to ﬁx it. And when you do implement the ﬁx, there is a good chance of
causing further problems. Brittleness is a somewhat loose term that cap-
tures the experience of coders struggling with working in what has become
a very difﬁcult and frustrating medium. Developers have problems tracing
causation in brittle technical systems, leading to an expansion of effort
required for even relatively small interventions.

Have you seen the old code? It was written without any levels of
abstraction whatsoever. That makes the code very difﬁcult to
understand because what you see is a whole load of very low level
mathematical operations and then you have to work out for yourself
what the big picture is and what all the bits are doing. And that is

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

473

hard to see. It was missing an awful lot of modern software
engineering, which is about making code that is either error free by
design or at least easy to deﬁne what the errors are (WS).

Brittleness compromises habitability. Working with and upon a brittle
Fluidity rendered research difﬁcult and time consuming. If a great deal of
time is spent ﬁxing bugs and tracing the logic of convoluted sections of
source code, there is very little sense of the code as an open and ﬂexible
medio. Its affordances dwindle. The modelling environment is less condu-
cive to just “trying things out” in the set-up of a simulation, following a
whim or an informal inclination. Not only do these processes take much
longer, it is harder for new collaborators to be brought on board. Uno
complaint with the old Fluidity was that it was hard for new Ph.D. estudiantes
to properly become experts in the code in the limited time span of their
doctorate.

The interface originally was very cumbersome. Only two or three
people in the group were able to use it. It was a big text ﬁle with lots
of random names. They all had to be six letters so it used all sorts of
crazy acronyms. It was very hard to modify the option system but
they were constantly adding new functionality so basically the
numbers became encoded in more and more complicated ways. Para
ejemplo, if you put a minus sign in the time step that might mean
something special. Or you put in a very large number with different
meanings for the different digits … Nobody really knew why it
broke when you changed something. It was a big project to step by
step change things to see where it broke and ﬁgure out why (HP).

5. Scale and Brittleness
What makes a software system brittle? Fluidity became brittle as it be-
came big and as the group developing it became larger, brittleness being
relative to scale. Es, sin embargo, difﬁcult to talk rigorously about the size of
software. There is no perfect measure. The most common measure is the
number of lines of code in the source code repository. This is the software
written by humans before it is compiled into binary code that can be
executed on hardware. But counting lines of source code is somewhat
arbitrary: different software languages use different rules of formatting that
take up different amounts of space. This is compounded by the fact that
Fluidity involves different languages working together. According to some
relatively standard calculations, sin embargo, Fluidity gets currently estimated
at over a million lines of code. At the point of the rewrite it already com-
prised more than a quarter of a million.

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

474

Brittleness and Bureaucracy

But the size of the source code is not a good measure of the complexity
of the code (Booch 2008). The complexity of the software architecture had
become a problem for the Fluidity developers. Because the code had grown
in piecemeal fashion, there was very little large-scale planning at the start,
and many additions were tacked on in inconsistent ways. A code that is
very large in terms of lines of code need not be complex for a human reader
to ﬁnd their way around. It may be very intuitively organized. En cambio,
even a relatively small code may have a torturous organization with many
headaches in store for a potential navigator.

A third element of the scale of software is the complexity of the pro-
cesses that it computes. Some software performs tasks that require a lot of
space to be encoded, but which are relatively conceptually simple, mientras
something like Fluidity is computing a lot of very complex mathematics,
and this considerably affects how manageable its source code is.

6. Making Fluidity Robust
As the group’s expansion got under way it became clear that the code
would only become more brittle as more scientists carried on adding
new functionality. Problems were compounded by the rate of develop-
mento. Some scientists were already refusing to work with the latest version
of the code because they were sick of results that they had gotten one week
no longer being reproducible a week later. The response was two-fold.
En primer lugar, there would be a complete rewrite of the code, completely reorga-
nizing its architecture and the style of programming in which it had been
written. En segundo lugar, a number of supplementary practices and technologies
would be adopted to help co-ordinate the work and to change the working
style of the group.

When the grant to develop ICOM [“Imperial College Ocean Model”
is Fluidity applied to oceans problems] arrived, all of a sudden a lot
of people were working on the development side. Code organization
and management became critical. We hired people who had good
ideas about testing, code structures, modularization (HP).

The complete rewrite of Fluidity took a small team about a year. Mientras
there was no funding earmarked speciﬁcally for this task, a number of new
projects were just getting off the ground and this work was built into their
early phases. The rewrite required a huge amount of work, but its pay-off
was to be a newly efﬁcacious, much more robust code. It is an extreme
measure to rewrite a code from scratch, but the new code re-implemented
the same core algorithms that had been developed over the previous 15 años
of Fluidity’s lifetime. While the work of expressing these algorithms in

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

475

software had to be redone, all the work that it took to devise them in the
ﬁrst place did not need to be repeated.

The “new Fluidity” did what the old Fluidity did, but it expressed it in
a more reader-friendly and manipulator-friendly way, organizing the core
algorithms so it was much easier to ﬁnd your way around the source code.
The new code used a newer version of Fortran and employed many new
stylistic techniques, all the way down to new rules for naming variables.
The modularity of the new code allowed new functionality to be added
easily and to interface with existing modules in a standardized manner.
A new options system with a clean and clear graphical user interface com-
plemented this process, speeding up the process of running new simula-
tions and tweaking them in the course of their investigation.

Things have moved on dramatically in the last few years … People
came in too who knew more about software development and
modern programming. Slowly what happened was that good practice
and rewriting the code in modern Fortran happened. The code we
have now has effectively zero lines in common with the code that I
started on. The algorithms are the same—these are the important
part, the hard part. The early stages of working on these codes are
getting the algorithms. But then get an algorithm and there are
hundreds of ways that you can code that, lots of choices of how you
implement it: different languages, different structures, diferente
orders of things that you do things in. One of the big things that
happens now in dev. [developers’] meetings are debates over this
kind of thing because there are lots of ways of doing something:
What is the best way to do it? And people have strong feelings about
este, making sure that things are useful for other people and future-
proof. In the old days you were only worried about getting
something working (NK).

The modularity of the new version of Fluidity was taken a long way.
Modularity in its extreme means that parts of Fluidity could in theory be
transplanted into very different modelling frameworks without having to
be retooled for the new job. Por ejemplo, in the main body of the code
we don’t code anything about the discretisation, so we can let things
change without having to recode. The code doesn’t even know it is a
ﬂuids model. It just knows it is solving PDEs [Partial Differential
Ecuaciones] (WS).

A complete rewrite of a software system is a radical tactic, and from a naïve
standpoint it may appear to signal a damning assessment of the old version
of the code. Sin embargo, Tiene, in principle, no bearing on the epistemic

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

476

Brittleness and Bureaucracy

legitimacy of the scientific arguments made on the basis of the simulations
created by the old code. From a deductivist viewpoint interested in the
validity of scientific discourse, brittle and robust codes make little differ-
ence. Exactly the same simulation, the same computational process, can be
generated by a brittle code as by a robust code. Or if these processes differ,
they may differ in no epistemically significant manner. Just because a code is
robust does not mean that the simulation it produces will give a more
legitimate answer to a given question. This issue is one of validation and
verification, which pertain to a finished simulation and not to the process of
writing and manipulating software. En otras palabras, brittleness and robust-
ness are properties of an environment for modelling that affect the processes
through which simulations are created, but which do not transfer to the
resulting simulations.

From a sociology of practice standpoint, sin embargo, the robustness of code
matters greatly. A robust code embodies greater potential than a brittle
code because it causes less frustration and less time absorbed with setting
things up and dealing with bugs. It is more habitable and facilitates a
greater degree of manipulation, and therefore offers a lot more potentiality
to surprise the scientists, to lead him or her down an unexpected path of
exploration towards innovative research.

Por otro lado, practical considerations are never wholly isolated
from the arguments made afterwards by the scientists. In the write-up
of results, the justiﬁcation of claims is accomplished by a drawing together
of a patchwork of arguments. Veriﬁcation and validation are usually the
major components, but they are never conclusive. A code that is known
to be robust and well-written is likely to include fewer bugs, so less likely
to involve bugs affecting the solution that have eluded detection in veri-
ﬁcation and validation. Even where these issues are not explicitly referred
to in publication, research communities are often well aware of the merits
and drawbacks of each other’s systems. Researchers move between groups,
interact at events, and seek out opportunities to try each other’s codes, y
the judgments they form about each other’s systems make a difference to
the general appreciation of their claims.

7. Social Technologies
Fluidity’s robustness was increased by the re-write. But it would be a mis-
take to think about manipulability solely as a property of the software it-
self. Everything depends on working practices. There is no straightforward
way to isolate the technology from the wider ecosystem of techniques
through which it is brought into use. The overcoming of the brittleness
of Fluidity was also the overcoming of the frustrations that arose from the
transition to working in a larger group. At the same time as the code was

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

477

being rewritten a number of what we could call “social technologies” were
introduced to the group, a holistic institutional adaptation, reconﬁguring
working procedures.

Research at AMCG now takes place between the gears of many different
systems for managing the speed of change, the size of the group, and main-
taining consistency and coherence of the evolving software. A full version
control system tracks every change made to the source code, while an
automated testing suite checks every new version of the code for errors.

Part of our quality control process for the code is all this testing and
that is both in order to make sure that new features that people
develop don’t cause problems but also to make sure that people
haven’t sort of messed it all up or literally made a spelling mistake or
get a wrong syntax (QH).

While I was there, the scientists were experimenting with a code
review system, so that every new section of software is reviewed by another
developer to try to pick up errors or just inconsistencies of structure or
style. A manual and user guide, and set of example simulations, are all
kept up to date so that new users can get to grips with the code quickly
and easily.

Some reviews are extensive … [The time commitment] can be
expensive but probably not as expensive as a bug getting in (HU).

Since November 2010, Fluidity has been open source, so new users
from around the world can download the software and they inevitably need
to be provided with support. By expanding the user-base, being open
source also has the advantage of enhancing the probability that bugs will
be discovered.

There are major advantages [to open source] in the sense that
hopefully we will have people across the world using our code. Y
they will ﬁnd bugs, guaranteed. They will report those bugs and
we can ﬁx them and that is all going to improve the validity of the
código (IW).
These technologies are justiﬁed by their proponents according to the
role they play in combating brittleness. They keep Fluidity reliable and
stable for its users. The code is changing all of the time, but if you got
a certain result last week, if it doesn’t work this week you know exactly
the version of the code in which it did work and you know who is respon-
sible for the change, and the automated testing system probably already
alerted you to the problem as soon as it happened, dampening the risk
of future delays to your investigations.

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

478

Brittleness and Bureaucracy

Por otro lado, the introduction of all these systems has transformed
the working style of the group. Together they regulate everyday research.
For every new piece of code, a test must be written, the user guide must be
updated, and a review must take place. Failed tests must be responded to.
Bugs must be logged, cross-checked, assigned, ﬁxed, and tested. Ejemplo
simulations for training purposes must be generated and documented.
Requests for help on the email lists and chat channel must be responded
a. Because the style and structure of the code must be kept consistent, el
group started having weekly developers’ meetings in order that everyone
can be kept up to date with all the other research projects that are cur-
rently going on and so that proposed changes and additions can be dis-
cussed before they are implemented. These meetings must be attended.
This tendency towards standardization and conformity ﬁts with classic
treatments of bureaucracy in the social sciences (for example Merton 1957,
pp.195–206). Work with old Fluidity, a smaller code with fewer collabo-
rators, could be quite individualistic, in the sense that scientists were free
to develop their own working practices, styles of research and ways of
communicating. They could keep each other informed of what they were
doing through informal means. A diferencia de, the social environment of the
new Fluidity is much more rule-bound, with extra time investments required
in order to keep each supporting system up to date and running smoothly.
It can be understood as bureaucratic because the group accumulates strong
norms pertaining to “correct” ways of doing things: a comprehensive set
of procedures that deﬁne how research should be carried out exist and must
be adhered to.

No es sorprendente, I would regularly observe friction between scientists
with somewhat polarized attitudes to the transition. Some felt that these
additional systems and processes were too extensive, that the workability
they facilitated was bought at the high price of leaving too little time for
doing the work that they saw as important, the research itself.

There are some people here who are very interested in how the
code is written so they like to have all these meetings and discuss
things all the time and update people. I understand you need various
things in place. But from a personal perspective I just want to do
ciencia (SOY)

The result is a broad division within the research group, between on
la una mano, those who self-identify as programmers and who are driven
by epistemic interest in the code itself, and on the other hand, those who
regard programming as a means to an end (this kind of division of orien-
tation is common [see Merz 1999; Sundberg 2008]). On matters of pro-
gramming, the former tend to exert authority, even in cases where they are

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

479

more junior in the ofﬁcial organizational structure. This created tension
from time to time when the programmers felt that the systems were being
neglected, when others failed to turn up to development meetings, o
when it was discovered that sections of the user guide were not being kept
up to date. On the other side, the non-programmers occasionally addressed
the division through light-hearted jibes. Por ejemplo, IW would refer to his
colleagues as a kind of police force, because he would often get in trouble for
“breaking the laws.”

There are people … I call them “the code police”… These are people
that really understand the code to a level that others don’t. Cualquier
changes that aren’t suitable they will say “look, that is useless,” often
with my changes, and say “do it this way, do it that way” (IW).

While the expression of these small frustrations was a regular feature of
my interaction with these scientists, they all recognized that these systems
were essential for the maintenance of a code of Fluidity’s nature. “Some-
times there is a feeling of being too software engineering focused but in
the long run you need to do that, otherwise you will end up with codes
that are impossible to run” (California). While interviewees would make their
resistance known to me, none of them went so far as to claim that Fluidity
could be better run in another manner.

8. Programming Systems Products
The tension between advocates of regulated practices and those who voice
resistance is a reﬂection of a general pressure that software exerts. Mientras
the agile practices discussed above are relatively recent, the ampliﬁcation of
effort involved in managing large software projects has been recognized in
the software engineering literature for many years. In his classic essay “The
Tar Pit,” Frederick Brooks analyzes precisely the kinds of frustration that
those like IM express when faced with the routines and processes of large
code development (1995). He noted that programmers working on big
projects commonly feel that if only they could be left alone, if only they
could just be free of all this bureaucracy, this feeling of wading through a
tar pit of daily routine, of meetings, processes and management, then they
could be so much more productive. The fresh air of freedom and they could
write many more lines of code; they could create something amazing. If brit-
tleness is one “material” property of software environments, the tar pit is
otro, the feeling of density and sluggishness imposed by the additional
organizational routines that grow up around the central task of writing big
software. “One occasionally reads newspaper accounts of how two program-
mers in a remodeled garage have built an important program that surpasses

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

480

Brittleness and Bureaucracy

that best efforts of large teams. And every programmer is prepared
to believe such tales, for he knows that he could build any program
much faster than the 1000 statements/year reported for industrial teams”
(1995, p.4). So, Brooks asks, “[w]hy then have not all industrial program-
ming teams been replaced by dedicated garage duos?" (1995, p.4)

El problema, says Brooks, is that this way of thinking is mistaken
about what it is that is actually being created in these different contexts.
What gets written in the garage is a program. A program “is complete in
sí mismo, ready to be run by the author on the system on which it was devel-
oped” (1995, p.4). It does the core task, and may do it exceptionally well.
But it works for that person, on that computer. What the big organizations
are after is something quite different: a “programming systems product.”
This is not merely a big code. It is a code that “can be run, probado, extended
or repaired by anybody… usable in many operating environments, para
many sets of data… written in a generalizable fashion … [con] thorough
documentation” (1995, pp.5–6). It also must conform with standard inter-
face design, with control on memory usage, tested in all permutations with
multiple other systems with which it is going to need to be able to coexist
and interact (1995, p.6). Brooks’ estimate is that to create a programming
systems product requires nine times as much work as a program, and it is this
ampliﬁcation of effort that gives the tangible feeling of sluggishness con-
sonant with working on big software compared with working on an indi-
vidual pet project.

Brooks’ essay is very helpful for understanding what took place at
AMCG during the transition from the old to the new versions of Fluidity.
It is also helpful for understanding the ﬁeld more broadly. There is a fun-
damental division in computational science between research that is done
with programs, y qué, por otro lado, gets done with programming
systems products. A lot of computational science is done in small groups,
with relatively short-term goals for the software, and a more ﬂexible atti-
tude to its longevity and portability. This software is written in the scien-
tiﬁc equivalent of a garage (probably the ofﬁce of a principal investigator
with a couple of his or her Ph.D. estudiantes, maybe a couple of postdocs). En
most of these cases there is no need to create a programming systems prod-
uct. You don’t need to worry about new people being able to get on board
quickly because the whole team was on board from the start. You don’t
need to worry about other groups using the software because they could
just write a similar application for themselves from scratch. You don’t need
the software to run on any computer but the facility that you have access to
for that project, and for which you have been writing from the start. Este
software is a relatively disposable means to an end. Its endurance is a “nice
to have” but the real output is discursive.

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

481

Por otro lado, a signiﬁcant subset of problems can never be tackled
with small programs because the kinds of systems that are to be the focus
of research are so complex that a large software framework is a necessity.
Some geophysical problems involve multiple interacting processes, operat-
ing on many scales. Software above a certain size requires a programming
systems product approach if it is to stay habitable, to remain material for
productive research. A big team needs to be coordinated around it. El
project will take long enough that some of the founders will leave and
new people will have to be brought on board part way through. It there-
fore has to be standardized and well documented. Hardware systems will
be replaced. Adjacent software systems such as compilers and operating
systems will be updated. The developers must be able to respond to these
changes without huge headaches. With complex geophysical problems,
the time it takes to build in all the necessary functionality and to validate
all the parts of the model is so great, that the software itself needs future-
prooﬁng. It is not just the money; careers are being invested. The legacy
needs to be more than the paper output of publications. It extends to the
software itself, itself a platform for further studies into the future. In these
casos, software is not just a means to an end. It is an output of scientiﬁc
activity in its own right, y, for that to be the case, the software and the
frameworks that surround it take a different form to small-scale endeavors.
It must be legible, extendible, and widely compatible, and this carries
with it signiﬁcant constraints on daily routine.

9. Conclusión
Both brittleness and the accumulation of supporting processes make de-
mands on time, whether it is time spent ﬁguring out how to make changes
or ﬁx bugs, or time spent adhering to new administrative routines for
tracking changes and logging bugs. These demands emerged as Fluidity
grew, and we can expect them to present general pressures on computa-
tional science research groups in many different ﬁelds. We can call them
“material” properties because they emerge at the point where a system of
writing exceeds its legibility, and becomes an artefact known through use
and manipulation as much as it is known through interpretation as a text.
Tendencies towards brittleness and bureaucracy could be discounted as
merely practical, having little bearing on the legitimacy of discourse.
But they play a major role in conditioning the investigations through
which such discourse is generated in the ﬁrst place. They are the geological
processes shaping the landscape of possibilities that scientists navigate
when they put their techniques into action.

And more than being just properties of scientiﬁc software, these pres-
sures also serve as drivers of motivation. Research in science studies has

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

482

Brittleness and Bureaucracy

explored the axes of desire, emotion and excitement that drive research
(Knorr-Cetina 2001, p.182). The picture this provides, sin embargo, necesidades
to be ﬁlled out by exploring the other kinds of concern that cut across
the epistemic, concerns with maintaining equipment under conditions
of stress, of holding things together in arrangements that threaten to break
abajo. These technical motivations are not isolated from epistemic moti-
vaciones; they gain their force from the latter. The focus on the framework,
on keeping it workable, portable, durable, arises from the intersection of
the properties of expanding software with its conditions of application as a
particular kind of medium for research.

Referencias
Bachelard, GRAMO. 1984. The New Scientiﬁc Spirit. Bostón: Prensa de baliza.
Bailer-Jones, D. METRO. 2003. “When Scientiﬁc Models Represent.” International

Studies in the Philosophy of Science 17 (1): 59–74.

Basili, V. R. et al. 2008. “Understanding the High-Performance-Computing
Community: An Software Engineer’s Perspective.” IEEE Software 25 (4):
29–36.

Arroyo, k. et al. 2001. Manifesto for Agile Software Development. http://

agilemanifesto.org/ [Accedido 16 December 2014].

Booch, GRAMO. 2008. “Measuring Architectural Complexity.” IEEE Software 25 (4):

14-15.

Bourdieu, PAG. 1977. Outline of a Theory of Practice. Cambridge: Cambridge

Prensa universitaria.

Arroyos, Jr., F. PAG. 1995. “The Tar Pit.” Pp. 3–12 in The Mythical Man-Month:

Essays on Software Engineering. Bostón: Addison-Wesley.

Easterbrook, S. METRO., and Johns, t. C. 2009. “Engineering the Software for
Understanding Climate Change.” Computing in Science Engineering 11 (6):
65–74.

Evens, A. 2006. “Object-Oriented Ontology, Or Programming’s Creative

Fold.” Angelaki 2 (1): 89–97.

Gabriel, R. PAG. 1996. Patterns of Software: Tales from the Software Community.

Oxford: prensa de la Universidad de Oxford.

Gibson, j. j. 1986. The Ecological Approach to Visual Perception. Hillsdale:

Lawrence Erlbaum Associates.

Giere, R. norte. 2004. “How Models Are Used to Represent Reality.” Philosophy

de Ciencia 71 (5): 742–752.

Goody, j. 1986. The Logic of Writing and the Organisation of Society. Cambridge:

Prensa de la Universidad de Cambridge.

Guala, F. 2002. “Models, Simulaciones, and Experiments.” Pp. 59–74 in
Model-Based Reasoning: Ciencia, Tecnología, Valores. Edited by L. Magnani.
Nueva York: Kluwer Academic.

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

Perspectives on Science

483

Heymann, METRO. 2006. “Modeling Reality: Practice, Knowledge, and Uncertainty
in Atmospheric Transport Simulation.” Historical Studies in the Physical and
Ciencias Biologicas 37 (1): 49–85.

Justi, r., y j. Gilbert. 2003. “Models and Modelling in Chemical Education.”
Pp. 47–68 in Chemical Education: Towards Research-based Practice. Edited by
j. Gilbert, oh. de Jong, R. Justi, D. F. Treagust, y j. h. Driel. Dordrecht:
Kluwer Academic Press.

Keller, mi. F. 2003. “Models, Simulation, and ‘Computer Experiments’.”
Pp. 198–215 in The Philosophy of Scientiﬁc Experimentation. Edited by
h. Radder. pittsburgh: University of Pittsburgh Press.

Kleindorfer, GRAMO. B., l. O’Neill, y r. Ganeshan. 1998. “Validation in
Simulation: Various Positions in the Philosophy of Science.” Management
Ciencia 44 (8): 1087–1099.

Klein, Ud.. 2002. experimentos, Modelos, Paper Tools: Cultures of Organic Chemistry

in the Nineteenth Century. stanford: Prensa de la Universidad de Stanford.

Knorr-Cetina, k. 2001. “Objectual Practice.” Pp. 184–197 in The Practice
Turn in Contemporary Theory. Edited by K. Knorr-Cetina, Theodore R.
Schatzki, and Eike von Savigny. Londres: Routledge.

Knuuttila, t. 2011. “Modelling and Representing: An Artefactual Approach
to Model-Based Representation.” Studies in History and Philosophy of Science
42: 262–271.

Knuuttila, t. 2005a. “Models as Epistemic Artefacts: Toward a Non-
Representationalist Account of Scientiﬁc Representation.” Philosophical
Studies of the University of Helsinki 8.

Knuuttila, t. 2005b. “Models, Representation, and Mediation.” Philosophy

de Ciencia 72 (5): 1260–1271.

Lahsen, METRO. 2005. “Seductive Simulations? Uncertainty Distribution Around

Climate Models.” Social Studies of Science 36 (6): 895–922.

Marick, B. 2008. “A Manglish Way of Working: Agile Software Develop-
ment.” Pp. 185–201 in The Mangle in Practice: Ciencia, Sociedad, and Becoming.
Edited by A. Pickering and K. Guzik. Durham: Duke University Press.
Matsumoto, Y. 2007. “Treating Code as an Essay.” Pp. 477–481 in
Beautiful Code: Leading Programmers Explain How They Think. Edited
by A. Oram and G. wilson. Cambridge: O’Reilly.

Merton, R. k. 1957. Social Theory and Social Structure. Glencoe: Free Press.
Merz, METRO. 1999. “Multiplex and Unfolding: Computer Simulation in Particle

Physics.” Science in Context 12 (2): 293–316.

morgan, METRO. S. 2012. “Models as Working Objects in Science.” Paper
presented at the Models and Simulations 5 Conferencia, June 14–16.
Morrison, METRO. 1999. “Models as Autonomous Agents.” Pp. 38–65 in
Models as Mediators: Perspectives on natural and social science. Edited by
METRO. S. Morgan and M. Morrison. Cambridge: Prensa de la Universidad de Cambridge.

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3

484

Brittleness and Bureaucracy

Netz, R. 2003. The Shaping of Deduction in Greek Mathematics: A Study in

Cognitive History. Cambridge: Prensa de la Universidad de Cambridge.

Oreskes, NORTE., k. Shrader-Frechette, and K. Belitz. 1994. “Veriﬁcation,
Validación, and Conﬁrmation of Numerical Models in the Earth Sciences.”
Ciencia 263 (5247): 641–646.

Ostrom, t. METRO. 1988. “Computer Simulation: The Third Symbol System.”

Journal of Experimental Social Psychology 24: 381–392.

parker, W.. 2009. “Does Matter Really Matter? Computer Simulations,

experimentos, and Materiality.” Synthese 169 (3): 483–496.

parker, W.. 2011. “When Climate Models Agree: The Signiﬁcance of
Robust Model Predictions.” Philosophy of Science 78 (4): 579–600.

Polanyi, METRO. 1983. The Tacit Dimension. Gloucester: Peter Smith.
Rheinberger, H.-J. 1997. Toward a History of Epistemic Things: Synthesizing

Proteins in the Test Tube. stanford: Prensa de la Universidad de Stanford.

Segal, J., and C. morris. 2008. “Developing Scientiﬁc Software.” IEEE

Software 25 (4): 18–20.

Suárez, METRO. 2010. “Scientiﬁc Representation.” Philosophy Compass 5 (1): 91–101.
Sundberg, METRO. 2008. “The Everyday World of Simulation Modeling: El
Development of Parameterizations in Meteorology.” Science, Tecnología &
Human Values 34 (2): 162–181.

Winsberg, mi. 2009. “A Tale of Two Methods.” Synthese 169 (3): 575–592.

D
oh
w
norte
oh
a
d
mi
d

F
r
oh
metro
h

t
t

pag

:
/
/

d
i
r
mi
C
t
.

metro

i
t
.

mi
d
tu
pag
oh
s
C
/
a
r
t
i
C
mi
–
pag
d

F
/

2
3
4
4
6
6
1
7
9
0
0
2
8
pag
oh
s
C
_
a
_
0
0
1
8
4
pag
d

b
y
gramo
tu
mi
s
t

oh
norte
0
7
S
mi
pag
mi
metro
b
mi
r
2
0
2
3
Descargar PDF