Working papers in
Information Systems
PROGRAMMERS A-VOIDING “COMPLEXITY”
Steinar Kristoffersen
WP 10/2005
Copyright © with the author(s). The content of this material is to be considered preliminary and are not
to be quoted without the author(s)'s permission.
Information Systems group
University of Oslo
Gaustadalléen 23
P.O.Box 1080 Blindern
N-0316 Oslo
Norway
http://www.ifi.uio.no/~systemarbeid
Kristoffersen
Copyright © with the author(s). The content of this material is to be considered
preliminary and are not to be quoted without the author(s)'s permission.
Programmers a-voiding “complexity”
Steinar Kristoffersen
Dept. of informatics
University of Oslo
P.O. Box 1080 Blindern
0316 Oslo
Norway
<steinkri@ifi.uio.no>
+47 2284 2409 (phone)
+47 2285 2401 (fax)
Citation: http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
1. Introduction
Information Systems (IS) research on topics such as project management (MacDonell
1994), design (Engels and Lohr 1994), programming (Joung and Smolka 1996),
methodologies (Hahn et al. 1997) and use (Buckland and Florian 1991) render the
notion of complexity absolutely central. It is used for many different purposes, but
most often it is either used to “scope” the work as being concerned with non-trivial
issues (Dampney et al. 1993), or it is used as a “strategic” approach, i.e., the problem
(whatever that might be) is ostensibly resolved by reducing complexity (Steward
1981).
Complexity is idiomatically everywhere in IS research, but the small study that is
reported in this paper shows that it may be completely missing as an explicit topic in
its own right, in a community of programmers working on what would elsewhere be
denoted complex projects (and rightly so).
This is particularly puzzling, since so many projects which are the targeted users of
the methods developed by IS research, quite consistently are seen to be falling short
of expectations (The British Computer Society 2004):
“Complexity can be a significant obstacle to successful design and delivery of
IT projects.
[…]
Research into methods to analyse and predict the behavior or complex
systems could lead to better assessments of the consequences of changing
specific requirements during the course of the project (ibid., p. 15).”
Elsewhere one might find a broad methodological, or even ontological, resistance to
the idea that methods were a good idea in the first place (e.g., Chapter 2 “Krisis” of
Ciborra 2002), and that the crisis is caused much more by methods that
“tend to disregard the fundamental role of the everyday world of the agents,
users, designers, and managers, and the messiness and situatedness of their
acting, […] In this way, they key element is neglected: human existence […]
(ibid. p. 18).”
Does this mean that the beleaguered domains are too “complex” as such, to be
managed by methods?
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
Deferring a more elaborate discussion of how the concept of complexity can be
defined until bit later in the paper, les us assume, informally, that complexity of a
system is made up by some combination of the number of elements within subsystems,
the degree of interactivity between subsystems and the uncertainty of the environment.
It is then, of course possible to see the task of developing any information system as
rather intricate (e.g., such as the illustration from Yetton et al. 2000 shows):
“Importantly, the complexity presented in [Figure 1 above] makes a strong
case for the argument that appointing a good project manager and following
a standard methodology would not begin to resolve the many relationships
which need to be managed effectively to deliver high project performance.
This helps to explain the relative failure in the IT industry to develop IS
project managers who consistently deliver projects on time, to functionality
and to budget. The challenge is too complex to resolve by a single intervention
(Yetton et al. 2000, p. 285-286).“
In any instance, however, unfortunately this does not help the community of
programmers struggling to get by, having to produce sufficient quality code within
agreed upon deadlines. Moreover, it is a frail argument on many levels. Within the
line of reasoning that one particular approach did not work because the circumstances
in question were too complex, then either there are cases (of a simpler nature) in
which they could work1, or everything is “too” complex. In the former case, a subset
of the original case would probably be simple enough to be dealt with using the
1
Conversely, if the environment is problematically uncertain, then that has to be “scoped” into the
method.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
method, which in its turn would reduce the complexity, etc., until the method could
successfully be applied on the remainder2, or this strategy is in itself “reflexive” in
the sense3 that decomposing the problems leaves the remainder more (and not less)
complex4. In the latter case, then either nothing would work (which, clearly it does),
or there is somewhere “a way of doing it” (i.e., a method) that works, but it is yet to
be explicated. This new “method” is either simply a traditional method thus far
undiscovered, or it relies on a different analytical pitch on the work of programmers
and the domains of which they are engaged, i.e., an alternative understanding of the
notion of “complexity”.
This novel theoretical understand of the concept of complexity is still vague, and one
might want to continue to try to pin it down analytically. Most certainly, the lack of
success on behalf of the methods that we have previously proposed to deal with
complexity indicates that a deeper enquiry into that notion is required. However, it
seems that it may be exactly because one has departed from an a priori and
decontextualized understanding of complexity (from within the system sciences
mainly), and then used that as a template for analytical approaches to the work of
programmers, that methods today are considered by many to be so problematic
(Ciborra 2002).
Ciborra’s methodological response to the problem of IS −as having devised “System
design methods may be the most diffused tools […], but they work only in part (ibid.,
p. 13)”− is, perhaps in one sense, provoking:
“Let us go back to the basics and encounter the world as it presents itself in
our everyday experience. We rely on evidence, intuition and empathy. We
listen to managers and we participate in their dealings with puzzles and
riddles, and, on the other hand, we do not confer any particular relevance on
works like ‘strategy’, ‘processes’, ‘data’, ‘system’ or ‘structured
methodology’ (ibid. p. 25).”
This is the exact objective of this paper: To look closely at the ways in which issues
that usually would be described as complex, are handled by programmers whilst
programming. The aim is to “unpack” the concept of complexity. The rationale is that
2
This is exactly the core of the “divide-and-conquer” argument of many methods and only proves that
methods can “work”.
3
Cf. Beck (1986)
4
It certainly cannot be both since would imply that that complexity means evasively large yet
reductionable, and evasively reflexive and unreductionable.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
if complexity indeed is used (too abstractly) to describe many different concerns, then
one should not be surprised that a professional enterprise (such as IS) that is oriented
towards resolving complexity, is not consistently successful. There seems to be,
simply, something wrong with the concept of complexity.
Therefore, this paper plainly raises the question of whether “complexity” is, bluntly
put, a “red herring” rather than a first-order attribute of information systems (work) in
its own right, or if is it just underspecified and much too general?
2. Using ethnomethodology
This is a fieldwork study, carried out through participant observation during a
sustained period of more than one year by (in average two days per week), with the
author working as a programmer in a related (“simpler”) project in the very same
room as the programmers that were the subjects of the study. The documentation
provided in this paper is based on transcriptions from mini-disc recordings of ordinary
conversations among this community of programmers. The subjects knew about the
study and its purposes. They were aware that their conversations might be recorded,
but they did not know exactly when.
Although ethnomethodologically-inspired studies of work have enjoyed some
prominence in CSCW and HCI over the past decade (Bentley et al. 1992; Martin and
Sommerville 2004; Suchman 1993), it is worth explicating it a bit further here since
this paper is not based on a “quick-and-dirty” ethnography (Rouncefield 1994). It
takes as its point of departure the most fundamental of all vehicles for getting work
done, namely naturally occurring conversations and thus, conversation analysis
(Sachs 1992). It does not purport, however, to cover all aspects of these conversations
from an ethnomethodological point of view. The conversation were monitored,
recorded and transcribed whilst looking for “instances of complexity”.
The ethnomethodological “pitch” of this paper means that, from the outset, abstract
concepts (such as complexity) and the relationships between them are not seen as
“proceeding” action in such a way that they can, in a stable way, constitute a (social)
order that is “given”, and that action (however voluntarily) can be seen as stipulating
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
the behavior of members of that social order. This is also the case for “complexity”.
So, this paper assumes that people do not regularly and stably enact (or respond to)
principles “of complexity” as if those were imposed upon them. In itself, however,
this position does not prevent “complexity” from being part of “a set of ‘commonsense’ entities which are, in practice, being constantly remade in significant ways by
members of the social order (Shapiro 1994).”
Conversation analysis is particularly useful for the purposes of this paper, inasmuch
as it can produce findings that are indisputable aligned with and anchored in
observable practices, as a means of rectifying theoretical ideas. It can show instances
in which the theoretical concepts are not stable, and equally interesting, it can show
the methods by which members of social settings “get by” even if their concepts and
conceptualizations of the situation break down.
Arguably the most conspicuous genre of ethnomethodological research, conversation
analysis is concerned with describing the methods by which the members of a culture
engage in social interaction. Its objective is to reveal the patterns by which
participants in “working through talk” structurally organize that communication.
Conversation analysis pays particular attention to detail, but not the particulars and
peculiarities of each and every setting; it is not looking for the exceptional or
sensational. Conversation analysis seeks to identify and represent the reproducible
patterns of the way we talk, in order to show the roles played by such patterns in the
production of order.
A conversation analytical research effort involves analyzing a set of samples of talk.
The samples are listened to, transcribed, examined and compared in order to reveal
their “orderliness” and the ways on which these orderly patterns relate to each other.
It proceeds from a detailed account of talk towards more generalizable descriptions,
by aligning the stable patterns thus discovered with the policies of the methodology,
e.g., such as formulated in (Garfinkel 1967). There is some bias in this, of course, and
it will (generally?) draw the researchers attention towards inductively discovering
central aspects of “being social”. However, and a bit more defensively, perhaps, for
this paper a more “traditional” approach to research is followed: This paper departs
from the hypothesis that “complexity” is a useful and much used notion among
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
programmers in ordinary programming community doing “extreme programming.”
The objective of the paper is simply to falsify this hypothesis.
Returning briefly to the policies of ethnomethodology, the words that people use in
naturally occurring talk and contact with other member of a community are indexical,
which means that that they are fundamentally contextual and cannot be specified in
advance, or in any “theoretical” way. However, in the exact circumstances of their
use, such words are instantly useful, and operationalized by the members. This is
according to Garfinkel (1967) recognizable as a practical achievement whose
qualities make the production of social order possible. Indexicality implicates that the
only reasonable approach to learn about a concept is through empirical investigation
of its usage in everyday practices, and yet the concept of complexity which IS so
often tries to “deploy” as a motivation and scoping of its methods, seem to have
maintained its stability and “meaning” through theoretical reflection rather than
empirical inspection.
This paper addresses this shortcoming, and has therefore come to rely on a method
that has the capability to “unpack” and put on display a social setting as it is
perceived, accounted for and enacted by those involved in that setting by the bonafide member of the community that is being studied. This is probably reinforcing this
method’s appeal to many researchers who are looking for input to theory building.
However, it is not without its problems, in this respect. First, ethnomethodology is
explicitly not concerned with creating big theories about external “normative”
structures that (may or may not) stipulate behavior; rather, it sees such “theories” as
part-and-parcel of the production of social order which all members of a community
is engaged in through and for the sake of “getting the job done”. Thus, the concept of
complexity and its qualities are no more a phenomenon that is “enforced upon
programmers” from the outside, than it is an aspect of “the account of programmers
work” as and when they work. Therefore, unless programmers “practice” complexity
in their work, the ethnomethodological analysis will contribute to our turning away
from complexity (as an almost metaphysical construct) and instead force us to focus
on the concepts that members of the community themselves are using. Second, it
might seem a laborious approach to discovering the commonsensical aspects of
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
ordinary work. This is true, of course, but it is at the same time a fundamental part of
conversation analysis:
“I take it that a lot of the results I offer, people can see for themselves. […]
And they needn’t figure that the results are wrong because they can see them
(Sacks 1992, 488)”.
It is a central methodological underpinning of this paper that if we (as members of a
sufficiently-skilled community of researchers) see things (through the eyes of
members that are programmers) as they are instead of as “complex” (if indeed they
don’t), then the knowledge about the alternatives will be helpful in analytical terms, a
well as when and if new methods are being invented.
3. What is complexity?
Complexity is of concern to a wide range of people in IS research. Xia and Lee (2004)
describe a framework for measuring the complexity of software development projects.
They take as their motivation an assumption that one reason software projects fail are
that they prove to be more complex than expected. They maintain that this is an
intractable or essential quality of such projects, because they have to deal not only
with technological aspects, but also with the wider organizational issues that are
beyond their control.
In their view complexity can be understood and measured along two dimensions:
Organizational vs. technological and structural vs. dynamic (ibid.). Whilst one can to
some extent see the logic of making structural (or stable) and dynamic two extremes
of a continuous axis, it is much harder to understand how the dichotomy between
organizational and technological is anything but rather arbitrary5. Certainly, there are
alternative interpretations of the relationship between technology and organizational
issues, for instance looking at the entire organization (of work) as a socio-technical
relationship (Bostrom and Heinen 1977a; b) or an actor-network (Law 1992) of
elements that through their being considered as having agency constitute a hybrid of
technology and society (Latour 1993).
5
E.g., why not differentiate between organization and processes, or organization and individuals, and,
for that matter, what is the distinction between organization and essentially structural aspects of any
community?
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
The view of Xia and Lee is on the other hand clearly representative for some parts of
IS, since they base their summary on a systematic review of the field’s work on
complexity. It communicates a rather strong positivist attitude, however; complexity
is a result of not being able to control the environment. On the flip-side, complexity is
also the result of (having to respond to) a changing “ecosystem” of organizations,
politics, requirements and technology. One interesting point that they identify is that
increased competition leaves less margin for error; organizations are now probably
more aware of problems relating to poor project performance. This means that
complexity, in some sense, also can be taken as relative to the consequences of not
coping with it.
Sometimes complexity becomes a reflexive attribute of technology itself:
“The rise of information system complexity, however, is driven by the
incredible capabilities and opportunities computing offers us (Schneberger
and McLean 2003).
The paper of Schneberger and McLean is mainly concerned with the complexity
imposed upon the architecture from the technology itself, and they point to the
“complexity cross” between simplifying components and taking on a larger number
(consequently) of interrelating component (ibid). Complexity is thus understood as a
function of the number of attributes in each component, and the number of
components. The argument shows that at some point the gain of simplification by
reducing attributes is cancelled out by the increasing number of components that are
then needed to contain these attributes. It is easily dismissed, e.g., by (routinely, one
might say, in IS and object-oriented design and -programming) suggesting that one
can aggregate related components into larger modules and thus hide some of the
complexity behind cleverly constructed interfaces. First, it simply reverses the
process. Second, it is, in itself, reflexive, since “the greater the number of modules,
the greater the number of interfaces among them (ibid., p. 219-220)”. This might
seem, one might have to admit, a theoretical argument, since empirically and
experientially problems are sometimes easier to solve when broken down into smaller
pieces. It is the stance of this paper that this is irrelevant, mainly because the concern
here is to find out how the communities of programming handle such issues (and if
that is different from how we conceive of their handling these issues), rather than
making an ontological argument.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
There have been other studies of programming and programmers as well. Departing
from a subjective interpretation of project complexity, Seaman and Basili (1997)
found that increasing complexity led to fewer defects being reported, which is
interesting, perhaps, inasmuch as they indicate that reduced exposure to errors (which
surely are there, even in a proportionally larger number than in less complex projects)
is partly due to lack of global overview. It seems that errors become recognized as
such only when they are embedded (conceptually) into a larger whole, and therefore
programmers working on larger (“more complex”) projects do not realize that are
maintaining an anomaly until later in the process.
This does not help us in coming to terms with “complexity” as such. However, it does
explain why the “cure” suggested by some has been to improve the architectural
aspects of IS design. The BCS report Challenges of Complex IT Projects (2004) is
particularly illuminating in this respect. It repeatedly makes the recommendation that
the system architect should be taken as a vital role in the implementation of complex
IT–systems. Unfortunately the definition of complexity given in the report is that it is
“multi-dimensional, encompassing scale, diversity, heterogeneity, etc. (ibid, p. 15),”
which does not really explicate the notion of complexity further. It (together with the
previous literature surveyed here) does however elucidate “complexity” as a concept
that covers many different aspects of information systems implementations. Let us
therefore look at the observable handling of allegedly “complex” issues, as
documented in en empirical investigation of talk among a community of “extreme
programmers.
4. Fieldwork
The research background of this paper is a company called Branova. It is a software
development and consultancy company. Their business idea is to provide software
solutions for the airline industry. The core competence of Branova is integrating
“ticketless” traveling and loyalty solutions with backend legacy systems, supporting
industry standards and processes. The company’s employees have several years of
experience in product development and software engineering from leading airline
companies. Past experience among Branova’s staff as well as consultants has proven
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
itself and their solutions are used throughout by one midsized company. It is now
marketed globally.
Airline ticketing and loyalty solutions are, fundamentally, systems for creating and
maintaining, distributing, marketing and selling all sorts of airline tickets in every
imaginable way. It has, moreover, become a way for airline companies to reduce
their operational cost and increase customer loyalty by introducing new business
concepts.
There has been increased competition about smaller market shares for airline
companies after “9/11”; many companies have had to shut down and the survivors
have been through radical transformations with regards to their product portfolio.
Portfolio transformations, tweaking and redesigning their offering to the market, and
changing their market profile is now the order of the day. Airline products are
intractably “complex” for a number of reasons, and the continuous and rapid changes
to that they undergo are another source of “complexity”. The notion of tickets as “too
complex to compare” in terms of pricing is well known, but of course this is dwarfed
entirely by considering also the associated deployment of materials and crew, as well
as the strategic and tactical implications that the airline company has too take into
account on their side:
“Using PC spreadsheets and calculators, analysts were taking days to
forecast the impact of a single flight change. Modelling an entirely new
schedule was out of the question. With deregulation, the complexity of airline
schedules began to increase exponentially along with demand, and deleting
one flight would affect hundreds of other connections. Executives wanted to be
able to respond to industry changes that were occurring on a daily basis from
competition, regulation or economic shifts (American Airlines/Sabre6).”
One specific example of such new products, designed to leverage the airline
companies competitive edge as other companies were launching new (primarily “oneway” products), can briefly be described as follows:
• A one-way pricing scheme in which different products (fare classes) can be
combined on out- and inbound flight in a return trip.
• Introducing a fee for changing the fare class (that this company did not have
previously), instead of restricting change to be either “up” (paying for the
6
http://www.cio.com/archive/020199_sabre.html
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
amendment) or “down” (taking a “cheaper” seat in an otherwise fully-booked
passage, as a way getting on an earlier flight).
• Variable fares for the same product, i.e., different booking classes within the
same product.
• Children’s discounts available for all classes, however, senior fares (which
used to be the same) and discounts for people traveling together removed.
• In addition, there are some products that have been contracted in advance
with the customer. They have different discounts according to the amount of
business that this customer is contributing.
• There are Internet-only products, and−
• There are products open to all channels, except that they are not yet available.
• Existing (already booked and sold) product have to be supported (of course).
Orthogonally to these basic structures, each product/fare class-combination has rules
that regulate various aspects, for instance:
• There are strict rules about which tickets can be changed into another after it
has been ticketed (although some of these rules are clearly incorrectly spec-ed
in the documentation), again, unless, they are changed after 12 hours before
departure, when no reissues can take place at the airport and fixed amounts
apply instead of negotiated fares.
• If cancellation happens less than 2 days before departure, they shall charge
25%, otherwise no invoicing ought to take place, unless the ticket was
changed to this class from a stricter one, in which case the original rule set
apply.
• Etc7. The point is that a large software system has to be modified in order to
accommodate for these changes. The suite of modules comprise (roughly):
• A Oracle RDBMS accessed in various ways (“batch-wise” SQL as well as
JDBC).
• An Internet Application Server, supporting.
• Webservices, J2EE (“Enterprise Java Beans”), etc., for remote access to the
database.
• A separate system for trading airline tickets with travel agencies.
7
The exact nature of these rules and changes are of no importance to the analysis of this paper and they
have been changed slight in order to comply with a NDA that governs the research described in this
paper.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
• The international linking of flights between airline companies through
AMADEUS
• A separate system for booking flight and buying tickets on the Internet
(figure 2)
• Etc. within an architecture looking something like illustrated in figure 3
The particular direction of the fieldwork of this setting thus became: When such a
substance is being changed regularly and significantly, how then do programmers in
this community “work” and talk their way through such work? If and how is
“complexity” and operational term for this community?
5. Excerpts from the fieldwork
This paper now turns towards analyzing the conversation between programmers in
this setting, looking not only for if and how they explicitly use the term “complexity”,
but also for ways in which they identify “complexity” in a different way—as intricate,
obscure, unfortunate, difficult, involved, complicated, multi-layered, may-faceted,
unclear, etc. It is useful tracking these down, because they represent alternative
concerns (rather than “complexity”) that could guide the work of programmers (and
thus IS researchers), and because, in looking at how they get presented, one might
find the underlying themes and actions that on behalf of the members of this
particular community are constitutive of what we might call “complexity”. Such
themes are valuable since they “unpack” the core concerns and “sense making” that
Figure 3 The system architecture
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
takes place in the group. In the next instance, conceptualization, problem solving and
methodological thinking (in IS) can build on these alternative or constitutive themes
rather than “complexity”.
The following excerpt8 shows a discussion relating to the reorganization of text in
various classes, i.e., the refactoring of code into smaller, more manageable modules in
order to make these classes more maintainable:
1: Can (.) you have to make a little bit smaller [], little bit smaller classes, not
so big classes, perhaps split it a little, that will make it easier
2:
[Smaller] How do you think that I
am going to achive that. Ehh. (..) Yes. Ehh. It is not going to be be smaller. It
is still going to be 21 pages of text. Maybe that is a little much, right? It
depends what you are comparing it to.
It provokes a rather harshly made remark, perhaps innocently phrased, but with an
emphasis on that which makes it critical.
1: [Hmm?] More? I hope that was a joke, [if it] was 10 files of 50 lines each
that would be easier that one of 500
2: [Yes, but, yes but] there are some reasons for that,…, first this
The tension is “defused“ rapidly, and the first speaker “backs off”.
1: [Okay, that] is okay. You don’t have to,…
However, the second speaker keeps on “making excuses”.
2: It is really a flow and it should really be partitioned, but I am not allowed
to do that bookinghandling and flowhandling, I need to that in advance and
the saleshandling we have to do elsewhere
It ends up becoming an account of the architecture that is currently in place, and how
the obtainable factoring is related to the overall organizational requirements of this
particular part of the system. This is certainly not an “alignment” of the IT system to
the requirements, since the architecture stays put; on the other hand the architecture is
not random, either. Code is designed for the purpose of “being good code”, and then
the justification is reframed in terms of a requirement specification afterwards. This
closes this part of the argument as well.
8
The subjects are not native English speakers, and the translation of the excerpts reflects that. The
objective has not been to write correct “English”, but make it correct “enough” whilst keeping the
authentic and original “flavour” of the exchanges.
Kristoffersen
The second talker then switches topic, and starts talking about deploying the code
(these are EJB (Enterprise Java Beans) that are compiled and tested locally, and then
deployed to a shared application server for more extensive testing in the group).
1: (Coughing) Is it okay by you that I do deployment in half an hour’s time?
2: Yes, eh, but (sighs) then you must test this class here, then, you are on some
cases now, right.
1: Yes, but I won’t be able to do that properly, it is only the EPL9 it does not
matter if that is out
The warning about a new deployment brings to the attention of both parties the need
for further testing, which in its next turn allows them to draw a clear boundary
between the work that is relevant right now with regards to the ongoing changes, and
that which is not. It is a “rescoping” taking place that also, in the next instance,
indicates which modules are not finished; it describes their status as “unknown”. It is,
in a sense, “activating slack”, in other words, making it clear that although it was
scheduled to be done already, it makes no harm that it is not.
2: The consequence if that merge there is that we don’t really what is
happening
Saying that “we don’t really know what happens” dissociates the code from any
particular person and person’s responsibility, since it does not say that the code is not
finished, or badly written, just that, in a sense, we don’t know exactly what it does.
Interestingly also, and there are many examples, this is usually coupled with giving
“it”, i.e., the code, agency of its own so that with no explicit disregard for the author
it is legitimate to not know exactly how to solve the problems at hand, for now.
1: I gather there are not that many of us right now doing EPL-testing so it
probably does not matter if,… (coughing)
The following excerpt show similar patterns of talk:
1: I was busy with that production problem that we had in Malmö last week
and I had to do something, (ehh), build a cache and something, so that it
wouldn’t,…
2: Ok, right.
1: That is why no-show fee was a little bit shoddy, and when I go in there to
look now, and there’s a bit more to do now than I though, (ehh), we never got
time to sync together, and he is using a booking class per journey, for instance
and I mean what is that, I mean, it is per trip, right? So
2: Did you get that reply that I sent to you?
1: You mean that “super-duper”?
9
Batchwise processing of booking requests.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
2: (Ehh), (he, he), no, you , but if you do not have a fee then you cannot go inn
and charge,
1: Well, I didn’t know what was necessary to get it to run, but I found out that
there was no value put in there at all, and the only thing working was B’s test,
that since there was nothing in the database,…, the VAT as test, so it wasn’t,
and the only thing that I wanted to find out was that the flow would go through,
and it did, and surely down there, in there, there were tax-codes, and suddenly
it throws it “down”, and then we run that VAT, so it wasn’t finished at all,
right, so it was just to see, to see if the invoicing was taking place, and the
machinery working, and then to look at the results afterwards, right, and it
was just nonsense, it was saying sort of “test data” here and “test data” there
and nothing like, so I have to talk to W tomorrow, because it is not exactly, W
was wondering if B had not spec-ed anything and I was thinking that perhaps
it as W who should have spec-ed it, (tj, he, he).
This is where we see again the code referred to as a “it” that does something, i.e., “it
throws it ‘down’” and “it was saying”, etc, so it is in a sense being
“anthropomorphized”. Moreover, the talker is claiming slack by circumscribing as
important “if the invoicing was taking place, and the machinery working, and then to
look at the results afterwards”, in other words, starting to work on getting the results
right later.
2: And there’s actually exactly the same problem here in production, first, two
things, first there’s that as always f***-all Oracle-date that he could not
handle properly so he had to test on the time,[
1: [Trunk, f***
2: :
and that means he did not find any prices,
and that was the one error, (.), the price was correct but he just did not find it,
just that day, and number two error was that when he didn’t find the price he
did not fail, he just invoiced then nil, and so their biggest customer got a free
ticket, (.)
1:
[(ehh), well, well,
2:
[(tji!), look at that, it was invoiced a naught
1:
[yes, I saw the reply
2:
[it is a disaster
1:
[yes, well, I saw
the answer but I didn’t understand was it was about, even
2:
[yes, yes, (he, he)
1:
[I was wondering have
they put in a data that it should give naught
2: Yes, but that is another thing, I mean if it is naught on your data in, then it
should be invoiced naught, bongo, then it should be invoiced naught, but if you
do not have any data, he, he,
1:
[yes]
2: so you can invoice them a thousand anyway (he, he)
1: Yes, but I got NULL, but I really don’t understand, and I didn’t understand
the code here, because we did not synch, sort of, before he went on vacation,
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
because he was sitting the whole of the previous week, right, implementing
that production s***. and I was asking W and,…
By the previous taker, the anthropomorphizing of code is even more obvious, because
he is referring to it as a “he”, which is becoming clear when the talker in saying“h e
did not fail, he just invoiced then nil” clearly refers to a runtime-occurrence. There are,
in other words, two “hims” in this excerpt; one is the programmer that has gone on
vacation and one is the server software that invoices customers (even, alas, if “he”
cannot find the correct trip).
1: Yes, but there must be some kind of exception if you cannot find the price,…
2: Well, but the way it is now, we will not, if we go to invoicing, now, we will
check if there are any invoice data there and if there is no invoice data there
then there is nothing to invoice (.)
Again, the “we” is code, but is examined analytically and “defensibly”. It now seems
to refer to us as in “the programmer and his code”.
1. N:o, but, what do then you mean then by invoice data?
2: Yes, so far we say that if you have not added any taxes, then that is not a
price
1:
[Mmm, but
2: proximally, that is not invoice, sort of,…
1:
[but then you have to put it out
there as an error, jupp, (snaps his fingers).
2: No, no, no, no, no, no no, no, no
1:
[Yes, because the rule says, that it should be something, so
therefore it
2:
[yes
1:
should either be one or nothing, because the rule is saying that there
should be a fee, and you cannot find a few then you must take it out
2: Yes, at least it should not be invoiced, but
1:
[no, it should absolutely not be
invoiced, you should mark it as an error and take it out
2: Out as an error? Out to where?
1: Just like any other error
2: There, then, did we did agree to take it down to EPL-processing, so
1:
[No
2:
[Yes, we agreed to make the EPL-processing such that we find
1: In EPL-processing should also put it out as error, or let it be on the queue
The talk about rules and how to understand them is a particularly telling example of
rules qua requirements’ specification being re-examined and re-formulated into
matching with what the program is already doing.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
There are two possible outcomes: One is that the requirements are still open enough to
allow the code to be kept. This does not mean that it is “acceptable” within an open
requirement for the code to do anything. Instead, the rules have to be interpreted and
formulated “within” the specifications so as to match the code. In the next instance,
this interpretation of the code can be tested against the customer’s rules until they are
accepted. The other is that the code definitely must be rewritten.
The discussion continues.
1: Yes, for instance
2: Yes, yes, yes, yes
1: At least it should not be a done deal
2: In EPL processing this will be a no-show (2) di-di, it is a no-show. The
EPL-processing has run a long time ago!
1: But how are we going to see this, then?
2: A little red blink on the screen,…, he, he
1: Whose screen??? This is a server-side service we’re talking about
So, the final part of this excerpt confirms that the specification at this point were (to
put it mildly) open enough to allow “incorrect” rules to be implemented within.
In these small excerpts we have seen examples of setting of/”claiming” slack,
anthropomorphizing the products, e.g., by attributing (offsetting or relocating) agency
and transferring “eidos” to code, and justification of existing design to match the
organizational requirements.
There is still a lot more to be learnt from these excerpts, and the analysis is still only
in its preliminary stages. Systematically though, from all the hours of observation,
complexity as a term is really never used in this community of programmers. The
question then becomes, what does that mean?
6. Discussion
Talk is perhaps the most central element of any social activity, and it is not just the
content that counts, it is the manner of talk. Social interaction includes non-work
oriented talk as well, of course, but this paper has been concerned with talk as work.
This paper has not in an inductive fashion made this into an extremely broad concern.
Neither was it the intention to “fill” the existing concept of complexity with various
interpretations. Given that the point of departure is that the definition of the concept is
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
rather weak, that could have been rather a tautological examination of (even more)
very different interpretations of “complexity. Instead, this paper has identified themes
that can be described as “epistopics” (Lynch 1993).
Epistopics represent constitutive starting points of a program directed towards
combining “ethnomethodology’s treatment of ordinary practical actions (ibid. p. 299)”
with the interests of its “contents”, which can be found in the sociology of science.
These pragmatical constructs are “the discursive themes that so often come up in
discussions of scientific and practical reasoning (ibid. p. 299)” and in programming
activities such epistopics could plausibly be planning, examining, design to meet
specifications, etc.
However, epistopics are not exactly the same across instances. Epistopics do not
contribute to an agenda of identifying stable concepts and developing theories of the
relationship between such concepts; instead they are topical “headings”, words that
may bear family resemblances10 across instances; “they allow us to see them as
similar (Tapper 1999, p. 449)”, but for which the underlying practices are not
necessarily governed by the same structures. “Complexity (management)” is the
“mother-of-all” epistopics, of course, in IS research.
This paper has identified and exemplified three explications of recurring espistopic
themes in the talk within a community of “extreme” programmers:
 Planning, as “Claming back slack”.
 Code inspection, as “Transferring agency and ‘eidos’ to code”.
 Design as “Justifying or adjusting a design to match perceived requirements” .
Planning and estimating is of course at the very core of how IS deals with complexity.
Finding out what to do, and when to do it in order to set and meet deadlines is, after
all, the externalization of success versus all the stakeholders. This is of course not an
easy task, and plans are probably often sketchy. Plans are useful resources for
programmers, but they can hardly be expected to be exhaustive or entirely consistent.
Plans are not the whole story, and even if they were people are not “programmable”
by plans (Ciborra 2002; Suchman 1987). Therefore, plans have “slack”. But “slack”
10
In a Wittgensteinian sense.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
is not just a breathing space, a vacation, or a sabbatical for the project members that
happen to be “there”. It is “real-estate” that can be claimed, and this is an important
part of the achievement that lies in making the plan work in practice.
The integral role of talk in practical laboratory sessions has been pointed to elsewhere
(Lynch 1985). It is a tool-rich and very physical” environment and it is claimed that
utterances often therefore are bound to objects and processes that are tangible in
nature. The coding practices of programmers are poles apart from this. Coding
involves working with abstract classes, ideas and concepts, rules and requirements
that may (more often than not) even be written down anywhere. This is perhaps also
the reason why code is so often given agency, by programmers talking about it as “it”
or “him” doing things on its own, and not only that: Code does things in certain
characteristic ways, that sometimes reflect back on the community or individual
programmers in terms of its “eidos”. This is one way of making software “less soft”
and thus, more manageable.
Lynch challenges researchers of social settings to “follow the epistopics” and
“investigate each case in accordance with a unique adequacy requirement (Lynch
1993, p. 302)”. This is exactly what happens when programmers make their preferred
solution “good enough” within the remainder of “interpretational space” that surround
pertaining requirements. Either is stands its test (the rationale for making it was that it
was successfully “overlaps” with the customer requirements), or the requirement is
iteratively narrowed down to close that space and force the responsible programmer to
redesign the code.
How can we then use these findings to better get to grips with the notion of
complexity? Well, in particular, IS researchers should pay attention to the noticeable
absence of explicit references being made to the work of programmers, by
programmers talking amongst themselves, as complex, complicated, intractable, etc.
Moreover, as a mundane way of dealing with phenomena that we, as IS researchers
(and programmers “externalizing” their work, as well) would describe as complex
issues, the epistopics above represent at least a complement to the “big” tactics of IS
methods: Generalization, modularization, decomposition, etc.; approaches that are so
much at the core of most modeling methods and programming languages (Andersen
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
and Dahlke 1990). These “tactics” are still valid, of course, but they should be seen as
offering a set of epistopic themes that in each and every instance then will take on
different forms. This paper is a continuation to understanding these forms and,
through that, it has contributed to “unpacking” the notion of complexity that these
epistopics are an aid to manage effectively. Arguably, resolving issues within such
epistopic themes is rather more about displaying an orientation toward “the relevantly
accountable details (Coulter 1994, p. 690)” as “conventionally constructed so as to
respect the assignable purposes of their prospective recipients (ibid., same page).
The world is, in a sense, generally complex, and there are of course many situations in
which talking about complexity as an externalized characteristic of situations is
warranted and relevant. However, for programmers as well as others, complexity may
be simply an elliptical expression that can be a result of the number of elements, their
interrelationship and dynamics. It may make project unfathomable, when the goals are
unclear or changing. This paper does not disagree with that. However, it is not
supported by the fieldwork presented here that pertaining issues are perceived,
examined or resolved as if they were indeed “complex”, and consequently, perhaps,
one should not be surprised when methods that aim to reduce complexity does not
work all that well?
References
Anderson J. A., and C. E. Dahlke (1990: Controlling complexity in Ada design
representation, Proceedings of the Ada-Europe international conference on Ada :
experiences and prospects: experiences and prospects, p.83-96, January 1990,
Dublin, Ireland
Beck, U. (1986) Risk society: towards a new modernity, London: Sage.
Bentley, R. (1992) , J. A. Hughes , D. Randall , T. Rodden , P. Sawyer , D. Shapiro , I.
Sommerville, Ethnographically-informed systems design for air traffic control,
Proceedings of the 1992 ACM conference on Computer-supported cooperative work,
p.123-129, November 01-04, Toronto, Ontario, Canada
Bostrom, R.P. & Heinen, J.S. (1977). MIS Problems & Failures: A Socio-Technical
Perspective, Part I: The Causes. MIS Quarterly, 1(3), 17-32.
Bostrom, R.P. & Heinen, J.S. (1977). MIS Problems & Failures: A Socio-Technical
Perspective, Part II: The Application of Socio-Technical Theory. MIS Quarterly, 1(4),
11-28.
The British Computer Society (2004). “The Challenges of Complex IT Projects”, ISBN: 1903496-15-2
Buckland, M.K. & D. Florian (1991). Expertise, task complexity, and the role of intelligent
information systems. Journal of the American Society for Information Science
42:635-643.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf
Kristoffersen
Ciborra, C (2002) The Labyrinths of Information - Challenging the Wisdom of Systems
Oxford University Press, Oxford 2002 (ISBN: 0-19-924152-X)
Coulter, Jeff (1994). "Is Contextualisation Necessarily Interpretive?" Journal of Pragmatics,
Vol. 21, 1994.
Dampney, C.N.G., (1993). M. Johnson and P. Deuble, Taming large complex information
systems, in D. Green and T. Bossomaier (eds) Complex Systems, IOS Press, 210--222.
Engels, Gregor and Perdita Lohr (1994). Visual Specification of Complex Database Actions.
East/West Database Workshop, pp. 303-314
Hahn, Hyoungmee, Jungpil Hahn and Jinwoo Kim (1997). A Cognitive Engineering Study on
the Development of an Object-Oriented Process Modeling Formalism. Proceedings of
the Thirtieth Annual Hawaii International Conference on System Science, 199-209,
(1997)
Joung, Y-J. and S. A. Smolka, A comprehensive study of the complexity of multiparty
interaction, Journal of the ACM, vol. 43, no. 1, pp.75-115, 1996.
Latour, B. (1993). We Have Never Been Modern. Brighton, Harvester Wheatsheaf.
Law, J. (1992). Notes on the Theory of the Actor-Network: Ordering, Strategy and
Heterogeneity. Systems Practice 5: 379-393.
Lynch, Michael (1985). Art and Artefact in Laboratory Science: A Study of Shop Work and
Shop Talk in a Research Laboratory. London: Routledge and Kegan Paul.
Lynch, Michael (1993). Scientific Practice and Ordinary Action: Ethnomethodology and
Social Studies of Science. New York: Cambridge University Press,
MacDonell, Stephen G. (1994). Comparative review of functional complexity assessment for
effort estimation, Software Engineering Journal 9(3): 107-116
Martin, D. and Sommerville, I. (2004). Patterns of cooperative interaction: Linking
ethnomethodology and design, ACM Transactions on Computer-Human Interaction
(TOCHI), Volume 11 , Issue 1, , Pages: 59 – 89, ISSN:1073-0516
Rouncefield, Mark, John A. Hughes , Tom Rodden , Stephen Viller (1994). Working with
“constant interruption”: CSCW and the small office, Proceedings of the 1994 ACM
conference on Computer supported cooperative work, p.275-286, October 22-26,
Chapel Hill, North Carolina, United States
Sacks, H. (1992) Lectures on Conversation, vol. 1. Oxford: Blackwell.
Schneberger, S. L. ad McLean, E. (2003). The complexity cross – Implications for practice.
Communications of the ACM, 46(9), pp. 216-225.
Seaman, C. B. and Basili, V. (1997). An empirical study of communication in code
inspections. Proceedings of ICSE, Boston, MA, USA, pp. 96-106.
Steward, D. V. (1981). The design Structure System: A Method for Managing the Design of
Complex Systems, IEEE Transaction on Engineering Management, vol. EM-28, no. 3,
August, pp. 71-74.
Suchman, L. (1987). Plans and Situated Actions, Cambridge University Press, Cambridge,
UK,
Suchman, L. (1993). Do categories have politics? The language/action perspective
reconsidered. In G. De Michelis, C. Simone, and K. Schmidt, (Eds.) Proceedings of
ECSCW '93 The Third European Conference on Computer Supported Cooperative
Work (September 13-17, Milan, Italy), Kluwer, Amsterdam, Netherlands, pp. 1-14.
Tapper, J (1999). Topics and manner of talk in undergraduate practical laboratories.
International Journal of Science Education, 21 (4), pp. 447-464.
Xia, W. and Lee, G. (2004). Grasping the complexity. Communications of the ACM, 47(5), pp.
69-74.
Yetton, Philip, Martin, Andrew, Sharma, Rajeev & Johnston, Kim. (2000) A model of
information systems development project performance. Information Systems Journal
10 (4), 263-289.
Number 10, 2005
http://www.ifi.uio.no/forskning/grupper/is/wp/102005.pdf