PLEASE SCROLL DOWN FOR ARTICLE

This article was downloaded by: [Lützhöft, Margareta]On: 19 October 2010Access details: Access Details: [subscription number 927468339]Publisher Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Theoretical Issues in Ergonomics SciencePublication details, including instructions for authors and subscription information:http://www.informaworld.com/smpp/title~content=t713697886

Ethnography re-engineered: the two tribes problemErik Styhr Petersena; James M. Nyceb; Margareta Lützhöftc

a Department of Technology, Lyngsø Marine A/S, Hørsholm DK 2970, Denmark b Department ofAnthropology, Ball State University, Muncie, USA c Department of Shipping and Marine Technology,Chalmers University of Technology, Göteborg SE-41296, Sweden

First published on: 30 September 2010

To cite this Article Petersen, Erik Styhr , Nyce, James M. and Lützhöft, Margareta(2010) 'Ethnography re-engineered: thetwo tribes problem', Theoretical Issues in Ergonomics Science,, First published on: 30 September 2010 (iFirst)To link to this Article: DOI: 10.1080/1463922X.2010.504284URL: http://dx.doi.org/10.1080/1463922X.2010.504284

Full terms and conditions of use: http://www.informaworld.com/terms-and-conditions-of-access.pdf

This article may be used for research, teaching and private study purposes. Any substantial orsystematic reproduction, re-distribution, re-selling, loan or sub-licensing, systematic supply ordistribution in any form to anyone is expressly forbidden.

The publisher does not give any warranty express or implied or make any representation that the contentswill be complete or accurate or up to date. The accuracy of any instructions, formulae and drug dosesshould be independently verified with primary sources. The publisher shall not be liable for any loss,actions, claims, proceedings, demand or costs or damages whatsoever or howsoever caused arising directlyor indirectly in connection with or arising out of the use of this material.

Theoretical Issues in Ergonomics Science2010, 1–14, iFirst

Ethnography re-engineered: the two tribes problem

Erik Styhr Petersena*, James M. Nyceb and Margareta Lutzhoftc

aDepartment of Technology, Lyngsø Marine A/S, Hørsholm DK 2970,Denmark; bDepartment of Anthropology, Ball State University, Muncie,

USA; cDepartment of Shipping and Marine Technology, ChalmersUniversity of Technology, Goteborg SE-41296, Sweden

(Received 3 December 2009; final version received 23 June 2010)

Does ethnography have anything to offer to the engineering community or thecomputer development community? Theoretically, yes, it does. Ethnography canprovide the skills and tools that will help us understand user needs and preferences,which can then be embedded into software and hardware. Still, it is difficult to findany discussion of commercial hardware or software products in whichethnography demonstratively played a decisive part, which has led some toargue that ethnography, as it is currently practiced in the computer developmentcommunity, would never have any practical impact. Bader and Nyce [Bader, G.and Nyce, J.M., 1998. When only the self is real: theory and practice in thedevelopment community. Journal of Computer Documentation, 22 (1), 5–10] raisedthis issue a decade ago, and argued that ethnographic knowledge appeared to belargely unintelligible and inoperable to the computer development community. Todate, this debate has not been taken much further, and the results of ethnographicresearch continue to be published in the HCI/Human Factors literature. The issuesBader and Nyce raised a decade ago have however not gone away: to what extentcan ethnography make a practical contribution to the computer developmentcommunity? This article picks up this discussion, re-examines the originalarguments and commentary, adds a Koenian view of engineering epistemologyto the analysis, and concludes that we appear to require a much improvedunderstanding of engineering epistemology, to support interdisciplinary commu-nication. Building on this foundation, what may furthermore be necessary is toperform an ethnographic operation twice, not just once: essentially, it is argued, itis necessary to build a kind of ethnography that takes the ‘interpretation’ ofresearch findings to one’s clients as seriously as it does the interpretation of whatgoes on in a particular, ‘targeted’ workplace for end-users. By providing this kindof ‘double’ translation and interpretation, it would be possible to ‘deliver’ethnographic findings to the engineering communities in a form they findintelligible, simply by doing what ethnography does best: the discovery andinterpretation of what is taken to be self-evident and logical.

Keywords: human factors; epistemology; ethnography; engineering; hardware/software development

1. Introduction: when only the self is real

In ‘When Only the Self is Real: Theory and Practice in the Development Community’,Bader and Nyce (1998) presented a provocative and pessimistic view on the role

*Corresponding author. Email: esp@lyngsoe.com

ISSN 1464–536X online

� 2010 Taylor & Francis

DOI: 10.1080/1463922X.2010.504284

http://www.informaworld.com

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

ethnography can have in software and hardware design and development. Forsythe (1999),in a piece written at about same time, raises many of the same issues. For a variety ofreasons which these authors describe, the design and development community seemedunable to make direct use of ethnographic analysis or its findings, even in projects wherethe ethnographers were directly involved, despite the pragmatic and analytic yield culturalanalysis seems to promise.

Bader and Nyce (1993, 1998) argued this had much to do with the low-value designersand developers attributed to ethnographic knowledge, and that this eventually results fromthe largely unacknowledged epistemological differences that exist between the computerdevelopers and interpretive social scientists. The argument presented is in alignment withthe way they previously and subsequently (Nyce and Bader 1995, 2002) have attempted tosketch out some of the epistemological elements that inform the software/hardwaredevelopment community. Within this spirit of these writings, the central Bader and Nyce’s(1998) paper discussed here describes not only the basis of this development community’sepistemology but also its ‘limits’, especially how the understanding of human behaviourand social life has become synonymous with common sense. In part, it is suggested thatthis has happened because of engineering beliefs about what is real, and the waysengineering determine what is real have much in common with positivism. Pragmatismunderlies and informs how engineering make sense of the world. In short, for engineering,if it can be seen, touched or counted, it is real. Because the development community hasnot spent much time thinking about how to study social life, it too has defaulted to thiskind of ‘common sense’ epistemology (Bader and Nyce 1998, pp. 9–10).

The epistemological gap Bader and Nyce (1998) claim exists, leads to threeepistemological mistakes they claim are committed by the development community.First, developers tend to mistake themselves for their informants. Second, the knowledgeof behaviour and the social world the developers and designers tend to operate on, morethan anything else reflects lay or folk models of society and the individual. Third, a kind ofempiricism, again which has its roots in engineering culture, leads information technology(IT) designers and developers to believe that knowledge and social behaviour canbe generated directly (deducted) from observation. Subsequently, these observations canbe readily described (translated) in terms of rules and laws, leading to the point that thetransition from rule to software code is seen as a pragmatic, and not a problematic, issueand operation. The result is that users and their requirements ‘disappear’, and, in the end,software and hardware is designed by designers for themselves. Further, the level andmanner in which this occurs means that the designers and developers themselves neitherrecognise, nor can account for, these epistemological errors.

Bader and Nyce concluded that

developers need to learn how to address the taken-for-granted, common-sense, structures ofmeaning that shape our social world(s). This is, we argue, an ongoing process. It is throughinteraction, the heart of social behavior, that we revise and change those categories that shapeour world and ourselves. Our best advice to developers at this point is to embrace contestedmeaning and the constructed nature of social life (1998, p. 9).

2. Reactions

The issue of Journal of Computer Documentation in which the original Bader and Nyce’s(1998) paper was published also contained four papers providing commentary on thispiece. The paper’s commentators did agree that ethnographic results had largely been

2 E.S. Petersen et al.

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

disregarded by the development and design community. As Bowker (1998, p. 11) puts it,‘there is ‘‘a demonstrable, fundamental gap between the knowledge the developmentcommunity values and that which cultural analysis yields’’’ [original quotation marks].Dillon (1998, p. 13) phrased this slightly differently but he agreed too: ‘Their [Bader andNyce’] conclusion, that cultural analysis yields knowledge perceived to be of little value bysystem designers, is in my view, largely correct’. While Rosson (1998) was silent on thispoint, Simonsen and Kensing (1998, p. 21) also noted that they

agree with the general picture drawn by Bader and Nyce when they argue that the kind ofknowledge and insight that cultural analysis produces does not fit the values and interests ofmost of today’s development communities.

3. Re-examination

While Bader and Nyce (1998) did point out what seemed to them the central, epistemologyissues that separate software and hardware developers and designers from interpretivesocial scientists, they however did not refer to the literature on engineering, its practiceand knowledge forms.1 This article will re-examine Bader and Nyce’s original argument,and the mentioned responses to it, and reconsider all of these in the present light of someof the literature that discusses engineering and engineering practice as an intellectualdiscipline.

By doing this, the original issue Bader and Nyce raised is explicitly re-examined as well:that ethnography does not appear to have much value to the engineering and developmentcommunity. The intent here is, once again, to raise the issue of whether ethnography canplay a significant role in the development process, and, especially, how this might comeabout, but it should be stressed that we limit our considerations to the maritime domain,where, experientially, software design activities are overwhelmingly carried out bydevelopers with a background in control engineering, software engineering or embeddedsolutions.

4. Knowledge and practice in engineering

The first step is to review some of what has been written on the role knowledge plays inengineering. Koen (1985, p. 16) argues that engineering rests on a series of differentheuristics, which he in general terms defines as

anything that provides a plausible aid or direction in the solution of a problem, but is in thefinal analysis unjustified, incapable of justification, and fallible.

Koen (1985) furthermore characterises a heuristic (p. 17) as:

. A heuristic does not guarantee a solution

. It may contradict other heuristics

. It reduces the search time in solving a problem

. Its acceptance depends on the immediate context instead of an absolute standard.

Using these heuristics, Koen (1985, p. 49) defines an important aspect of engineeringpractice by ‘Heuristic: always give an answer’. In our understanding, this implies thatengineering practitioners are trained (and expected) to always be able to provide ananswer, even on the thinnest of evidence, and under the most constrained of conditions,e.g. short response-reply times, and limited resources. The utility, applicability and

Theoretical Issues in Ergonomics Science 3

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

precision of an answer is always directly coupled to (and informed by) local context and aparticular timeline. If you expect an answer from an engineer in seconds, you may get arule-of-thumb reply. If he has hours to respond, you may get a rough calculation. If he hasmonths, you may receive a more precise answer derived from a thoroughly validatedcomputer simulation. What however has to be kept in mind is that all these replies are seenas correct from an engineer’s point of view (Koen 1985). In short, the context, e.g. localcontents, time frame and time limitations, of the question has to be taken into accountwhen it comes to appraising the accuracy and precision of an engineering response toa particular issue.

4.1. Best practice in engineering

For Koen, heuristics in some combination or another provide the operational basis ofengineering. Each heuristic set, as refined and validated over time, constitutes for engineersbest practice, or what Koen calls a ‘sota’ – short for ‘state-of-the-art’. Engineering sotas aretime and date stamped. What is best practice today may have changed tomorrow, becausethe relevant heuristics themselves may have changed due to social or technologicalchanges. This is also why, according to Koen (1985), engineering has developed as it has, atopic we will discuss later.

Koen believes that state-of-the-art is always tied to (and reflects) a particular context.This separates engineering from positivistic science in which context is either somethingthat can be controlled or is regarded as irrelevant. Engineering is not looking for anoptimum (or universal) solution, but a workable solution given time and resourceconstraints. This implies that a car, a dog basket, a nuclear submarine or a word processorthat fulfils a number of basic functional requirements, given the time and solution space,is acceptable. Having said this, the balance between empirical and analytical approaches toengineering is not a constant. It is determined in part by history and by culture as well aslocal constraints and context (for example see the Kranakis (1997) study of nineteenthcentury American and French engineering practice). Koen (1985, p. 65) makes much thesame point when he observes that while science has fuelled the machinery of modernengineering, it is not the machinery itself, and proposes that engineering should use theheuristic of ‘apply science when appropriate’.

4.2. The epistemology of engineering

Engineering is understood by society, and by the engineering community itself, to evolve inmeasured steps, driven by experience. Its progress is continuously validated andlegitimatised through learning/teaching others, professional discourse, intercommunityinquiry and debate (Bella 1987). Further, what informs engineering practice is not any onekind of paradigm, but a number of sotas, combining empiricism with pragmatism, andproblem formulation with problem solution – something that has been noted by otherauthors as well (Vincenti 1979, Ferguson 1992). For Koen, this kind of practicalexperience-based epistemology leads to a view of the world in which no single method orsolution is valorised (held up as a universal standard). In short, what constitutes adequacyin engineering is determined by context, the resources available and a particular timeframe. This also again highlights the difference between engineering and science. As Koen(1985) phrases it, an engineering solution is simply a strategy for causing the best change ina poorly understood or uncertain situation within the available resources – implying that

4 E.S. Petersen et al.

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

engineering tends to offer as solutions what they understand as optimal, given the context.However, an important part of the engineering mentality is to be cautious, goal-orientedand not to be put off by a lack of information, and to make the best choice(s) given theavailable resources and context. Eventually, Koen (1985) reduces all this to his Rule ofEngineering

Do what you think represents best practice at the time you must decide, and only this rulemust be present (p. 42).

The criteria used to select the heuristics for best practice reflects how engineeringdefines ‘best’. This includes evaluation processes where attributes of development cost,product cost, benefit, impact and side effects, which often are directly incomparable, arenevertheless weighed against each other (Koen 1985). This process should also take intoaccount (and reflect) the sum of expectations derived from all the stakeholders involved inthat particular engineering project. However, this may not always be possible due to anynumber of factors like miscommunication, misconceptions or simply a lack of information(Busby 2003), or, as Vaughan (1996, p. 196) believes, because engineering have‘a worldview that survives despite evidence that repeatedly challenges it basicassumptions’.

Be that as it may, Koen’s Rule of Engineering demonstrates the crucialimportance best practice plays in ‘everyday’ engineering. Consider, furthermore, theimpact of best practice when seen together with the heuristic of ‘Always give ananswer’ (Koen 1985, p. 49). This heuristic, we suggest, describes the mechanism withwhich engineering practice responds to time constraints or otherwise limited resources,all of which are factors that are inherent in engineering practice. We further believethat the response described by this particular heuristic is a core component ofengineering epistemology and the basic nature of engineering, and something whichrequires further research.

Nevertheless, it would seem that as market pressures move up, and the product lifecycle shortens, engineering is pushed to respond along these lines of ‘always give ananswer’: more and more heuristically, more and more depending on (simplified forms of)best practice, and less and less applying costly and time-consuming case-by-casedevelopment.

This affects how ethnography, usability and user-centred design, probably amongmany others, fare in modern, industrial engineering practice. As Gulliksen et al. (2006)reports, usability and user involvement are typically among the first items to be abandonedwhen the development project schedule gets tight. We concur; the willingness to disregardusability as a development activity when the time pressure mounts on the developmentteam is an ever-present risk, as has also been confirmed by the recent research(Petersen 2010).

However, while a shortened development cycle in this way very well can be at theexpense of the usage of ethnography to inform the design, of user-centred design or ofother similar practices, it importantly also highlights the status of these paradigms andmethods within the body of engineering knowledge: they are simply not part ofengineering best practice. If they were, they would not be cast overboard when the goinggets rough, but with the pragmatism of engineering, be reduced towards more and moresimplified heuristics. This line of thinking, we finally suggest, also leads to the conclusionthat any kind of sustainable expansion of engineering practice has to be thoughconstructive interaction with the universally accepted body of engineering knowledge, if itis to have a wider impact.

Theoretical Issues in Ergonomics Science 5

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

4.3. Epistemology in hardware/software design and development

Whether this all holds true for software/hardware designers and developers is somethingthat requires further research. Having said this, practitioner accounts link design and

development to computer science. In fact, IT design and development is generallyportrayed by practitioners as resting on a scientific epistemology. There is, however, little

in the literature (except in computer science textbooks) that suggests this is true. Rather,to believe that any innovation or elaboration in a technology suite like a computer

platform can be equated with science or scientific research is, given what we know today ofengineering and science, naıve. Often these claims can be traced back to the identities that

von Neumann argued existed between mind and machine and between biology and

computer ‘science’. In short, the fact that these claims are still taken seriously tends toobscure the actual relationship computer ‘science’ has both to science and engineering.

This is testimony, more than anything, to the hold that the von Neumann architecturecontinues to have on modern intellectual thought.

However, when what underlies and informs computer science is looked at carefully and

critically, we find something quite different. For example, Holloway’s (1995) study of thefield of computer science found that there is no full-fledged software engineering

epistemology. Elsewhere, Holloway (1996, p. 2) claims that ‘the development of softwareengineering is following the same pattern as the development of many other disciplines

[in engineering]’ and links software engineering to civil engineering, chemical engineeringand aeronautical engineering, thus establishing that software engineering has more in

common with the engineering than science. He goes on to show that software engineeringrelies on anecdotal experience and the authority of the ‘experts’ [original quotation marks]

(Holloway 1996, p. 2), which puts computer science squarely in the middle of the Koenianuniverse. Koziolek (2006) notes that many authors have noted that the kinds of

experimentation found in software engineering have little in common with best practice inscience, and, we hasten to add, appear to have limited practical impact on best practice in

software engineering: in a comprehensive survey, Neill and Laplante (2003, 2004) find thatthe traditional methods for software development lives on undeterred. As such, the

Evolutionary, Incremental and Waterfall methods for development are applied in more

than three-quarters of the industrial projects surveyed, and ethnography, in the context ofrequirements engineering, have a score of 0%, lowest of all methods rated.

One might want to believe that software engineering, and with it, the design and

development community, had developed a more nuanced epistemology in the decadewhich has passed since Holloway and Bader and Nyce have published on the subject.

There is, however, little evidence that suggests that such an epistemology has developed.In fact, Cuadrado-Gallego et al. (2007, p. 1168) find that ‘there are few laws, theories,

hypothesis or conjectures in Software Engineering’. Further, as Aaby (2004) has noted,software still tends to be designed, developed and deployed in ad hoc, opportunistic ways,

often without any, let alone sound, epistemological foundations.

5. The first move: towards a cartography of epistemologies

We have sketched out what constitutes legitimate practice in engineering as well as anepistemology that links the IT design and development community more to engineering

than science. In brief, we suggest that Koen’s (1985) and Bella’s (1987) findings apply tosoftware design and development as well as to engineering. It is also clear that if any

6 E.S. Petersen et al.

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

attempts have been made to place software engineering practice on firmer epistemologicalground, these efforts have not been very successful.

The discussion so far has attempted to describe some fundamental elements ofengineering. Knowledge, as engineering understands the term, tends to be empirical,pragmatic and utilitarian. This means that, given the multitude of factors, organisationsand individuals involved, engineering tends to employ something like best choice theory.The role metrics (Sotas, or best practice) play in negotiating for engineeringseemingly incompatible or incomparable elements like resource sets, timelines andcontexts (micro to macro) has also been pointed out.

One intent of this article is to examine to what extent the Bader and Nyce (1998)argument holds true given what is suggested to be known about the theoreticalunderpinning of engineering. Bader and Nyce argued that ethnographic knowledge andanalysis has little value to the IT development and design community largely because thereis a fundamental epistemological and philosophical distance between ethnography, aspractised in the interpretive social sciences, and engineering.

Taking into account what those who have attempted to describe the epistemology ofengineering have had to say (Koen 1985, Bella 1987, Vaughan 1996, Busby 2003, Kerr2008), we are led to two conclusions. First, the epistemological gap that Bader and Nycedescribe between ethnography and engineering does exist. In fact, the literature suggeststhat there is a very large distance between interpretive ethnography and the kind ofexperiential epistemology that characterises engineering.

Second, the observations made by Bader and Nyce about IT developers and designersseem accurate and credible. They might not even be very surprising, given the vantagepoint of the observers: these engineers were seen to commit what Bader and Nyce (1998),construed as two epistemological errors. The first is (mis)taking yourself for the user. Thesecond is the misunderstanding and the misuse (the quantification) of qualitative data.

What is however perhaps surprising, but nevertheless clear from the above analysis, isthat this interpretation of the actions of the observed engineers probably is attributable tothe very same epistemological difference that is being discussed here. In fact, what Baderand Nyce describe as epistemological errors may very well be an observation ofengineering practitioners acting as engineering practitioners are supposed to do: they usedbest practice. They also handled uncertainty by understanding and reducing complexity toa set or series of heuristics. The result is that these engineers were able to build systems thatmet basic functional standards, if this means that the systems they designed were deployedand put to use.

What needs to be stressed is that for engineering, neither of the errors that Bader andNyce (1998) describe comes close to being anything like a mortal sin. From an engineeringperspective, ‘mistaking’ yourself to be the user is simply a way of overcoming uncertainty,when better data are not available – or understandable. Under these circumstances, this isseen in fact as good engineering practice. Keep in mind that engineering practitionersseldom have the kind of training or education that allows them to appreciate ethnographicdata, and especially the issues this particular error raise for those who carry outethnographic research. The result is that engineering tend to appropriate fromethnographic data what it finds meaningful and useful, on the basis of engineeringknowledge. Further, engineering tend to use ad hoc, tacit measures and heuristics to sortout what is relevant and not in this data. In any design and development project, both bestpractice and certainty is hard to achieve, and not fully appreciating all the facets andimplications, and all the potential significance ethnographic results might have, is notsomething hard/software engineering, in the midst of a project, would worry much about.

Theoretical Issues in Ergonomics Science 7

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

Quantifying qualitative data, the second sin that software engineering commitsaccording to Bader and Nyce (1998) is also not a mortal sin as engineering practiceunderstand the term. For engineering, quantification is seen as the only way one canperform the kinds of trade-off analysis engineering is tasked with – ones in which there isnot just a large data volume but the data itself represent different, even incommensurableorders of facts and things like ‘completion date’ versus ‘usability’. For engineering, using aquantitative metric to help sort these factors out seems entirely rational.

6. The second move: who should change?

The above section suggests that the sins committed by the engineering community,according to Bader and Nyce (1998), are not errors per se, but are instead naturalexpressions of the epistemological differences that exist between two different intellectualcommunities (that of engineering and that of interpretive social science). This brings us tothe next question. What and who should change to narrow the epistemological gap? This isin part a philosophical question, but one that can have, we believe, significantpragmatic yield.

6.1. The development of engineering knowledge

To answer these questions, we have to look briefly at how engineering knowledgedevelops. According to Koen (1985), this can be described by two heuristics:

Heuristic: Make small changes in the state-of-the-art (p. 51)Heuristic: Use feedback to stabilise engineering design (p. 55)

Bella (1987) agrees with Koen. He describes engineering as a disciplinary communitythat shares a knowledge base, a paradigm – which he defines as ‘integrated systems oftheories, concepts, laws, procedures, examples, models and techniques’, which he suggestsconstitutes the expertise of the community (Bella 1987, p. 119). Note again thatthe paradigms evolve through a social process or processes in which the members of thedisciplinary community interact with society through technological actions, andsubsequent input and feedback which Bella terms observations. The currency of theknowledge base is maintained through discipline, which is the community’s way of policingthe integrity of the paradigms. Further, both community members and innovation aredriven by observations. We are not arguing here for any kind of crude progressive, socialevolutionary model of science or progress. Kuhn (1962) and much of the recent study inthe sociology of science should have disabused us of beliefs like these. As to how theengineering knowledge develops, Bella (1987, p. 122) puts it this way: ‘The knowledge ofa community evolves as shared innovations become accepted as paradigms fortechnological activity’.

The social interdependency of members in a disciplinary community is implicit in this.In spite of the emphasis Bella places on discipline and trust, credibility and verificationremain important factors when it comes to knowledge production within a disciplinarycommunity and in the relationships it has with society at large. Without all these factors inplace, engineering knowledge could not develop, in part because the discipline would notbe able to define certain innovations as things that cannot be proven (Bella 1987).As with any discipline, the result is a kind of prudence, or perhaps even conservatism, withpractitioners preferring to err on the side of caution.

8 E.S. Petersen et al.

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

As a result, engineering tends to develop incrementally, through observing how a

solution works out in the particular context it was developed for, or how a design method

provided a benefit. Peer acceptance of a solution, whether process or product, rests on theextent to which it can handle a large set of diverse, often conflicting, variables such has

durability, usability, maintenance, development cost, development time and production

costs. Given the number and kinds of elements that have to be considered, any method or

solution reflects a number of trade-offs or compromises. Further, when assessing one

attribute against another, a common yardstick is required, and more often than not costbecomes the deciding factor.

6.2. Engineering towards ethnography

Koen (1985) recognises that engineering can find itself in a position where a particular

engineering ‘sota’ is insufficient, and where the heuristics required do not yet exist within

the engineering domain.When this is the case, engineering have two options: evolve or relyon other professional communities, like the scientific community, to supply the required

knowledge. At first glance, Koen’s (1985) argument might lead readers to believe that

engineering does not have to evolve at all to accommodate ethnography. If, for example,

ethnography is believed to be ‘within the engineering domain’, the issues it raises can be

perceived as trivial or things that engineering already can handle. This is what happenswhen engineering reduce ethnography to just ‘common sense’, as Forsythe (1999) has

argued.However, if engineering avoids this reduction, and realises that ethnography is more

complicated than this, Koen describes what the possible results might be:

Only two ways of solving problems in [this area] are possible. Either the engineer can delegateresponsibility for certain aspects of a design to the lay person and accept his input no matterhow unreasonable it seems, or he can increase his general sensitivity to the hopes anddreams of the human species – that is, increase the overlap of his sota with that of society(Koen 1985, p. 40).

This is an interesting dilemma for engineering. Even if we leave out comparatively

non-trivial issues (like power and authority), neither of Koen’s alternatives are reallyattractive to engineering. The first option runs against both the ontology and epistemology

of engineering, to say, nothing of the challenges it presents to the profession’s legitimacy

and creditability. As such, the first option is the one most likely to be rejected. The second

is not much more attractive given the mutual mistrust that exists between the majority ofprofessionals who make up the engineering and the philosophy/interpretive communities,

which includes the social sciences (Kerr 2008).This leaves us with a similar dilemma. Either we have an engineering community that

believes that ethnography is reducible to something like common sense, or we have an

engineering community that realises it has something to learn from ethnography, but, wesuggest, only because of the value it provides: without demonstrably providing a direct

benefit, we speculate that any new method or paradigm will fail to become part of

engineering best practice, and will never become the ‘shared innovation’ that Bella (1987)

describes as being the fuel for development of the engineering body of knowledge. In

consequence, it will not be adopted, and it will not provide improvements to the end-usersor consumers, as is the intention of ethnography in HCI. Advocating that a value-driven

interaction with the engineering body of knowledge is imperative, we find ourselves

Theoretical Issues in Ergonomics Science 9

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

concurring with Dillon, who in the original commentary to the Bader and Nyce’s (1998)study note that

. . . designers trained in engineering and required to produce working tools are never likely toappreciate the subtleties of ethnography as long as it fails to demonstrate significant practicaladvantage for them . . . it is a case of showing what difference any information makes topractice (Dillon 1998, p. 14).

Further in order to gain maximum profit from ethnography, engineering will have tolearn to advocate for the strong, interpretive kinds of ethnography (see Nyce and Lowgren(1995) and Dekker and Nyce (2004) for discussions of what characterises strongethnography).

6.3. The reinvention of ethnography

The onus here is not on the members of the hardware/software design and developmentcommunity. What we are calling for is a kind of Janus-faced ethnography, one in whichthe knowledge demands and information requirements of the ethnographer’s clients andcustomers have to be mapped and understood as carefully as those of one’s end-users.What has to be done is to pick up where Bader and Nyce more or less stopped. This wasnot lost on some discussants of their paper. Bowker (1998, p. 12) suggested that

. . . there are a lot of rich possibilities for cultural analysis within the various developmentcommunities, and that good ethnographic studies can bring to light the shape of thosepossibilities.

Rosson also picks up on this theme when she suggests that ‘Bader and Nyce shouldthink more carefully about how to present their concerns to . . .developers’, while Dillonoutlines the challenge to the social science community in clear terms:

Academic studies of human behavior are complex, difficult to perform, and require someunderstanding of theory to appreciate their outputs in many cases. (Dillon 1998, p. 14)

To convey the necessary understanding of ethnographical findings, and hence toprovide usefulness to the engineering community, we suggest that what is required is akind of parallel, interlinked ethnography of both users and clients (Lutzhoft and Nyce2008, Rasanen and Nyce 2008) for which there is little precedent in the literature. Wesuggest this in spite of the caution that Dillon advocates in the original commentary, whenhe notes that

Social science studies, in and of themselves, do not exist to serve outside purposes, be theydesign or otherwise, but to increase our understanding of humans, and we should neverdemand of the social sciences in their pure form that they offer direct guidance to softwaredevelopers (Dillon 1998, p. 14).

In fact, this is the change on the side of social science we advocate must take place:while there is a literature on ethnography as a research enterprise, this is largely meant tosupport classroom activities and/or provide guidance to graduate students aboutundertaking their first ethnographic research. So far, however, little attention has beengiven to the kind of ethnographic project outlined here.

This ‘doubling’ of the ethnographic project has also been little discussed in theanthropological or social science literature. This is largely because the issues it raises havelittle salience when an author is writing for an audience (a group or tribe) in whichone is also a member. In effect, a kind of professional, disciplinary solipsism, a tacitagreement about what constitutes appropriate writing and argument, exists in almost

10 E.S. Petersen et al.

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

every scholarly community and this finesses the issues raised here when we just write forour peers. Even in discussions of dialogic or collaborative ethnography, the emphasisremains on exploring translation and interpretive issues that are problematic inethnographer–informant relationship (Lassiter 2005). While the literature on appliedanthropology does recognise that one’s informant and clients and understandings of thekey concepts may differ, the issues raised here tend to be reduced to comparatively trivialones in the literature. For example, these discussions will centre on questions, like whatconstitutes an ‘effective’ presentation of research results, and quickly default to graphicdesigns issues regarding report format or PowerPoint presentations. However, theliterature on applied anthropology, more than anything else, tends to assume that ‘goodfaith’ and traditional forms of reportage and analysis are enough to bridge whateverepistemological distance exists between an ethnographer and his informants and betweenan ethnographer and his clients. Further, the subdiscipline’s stance reads out: advocacytends to mask the issues we have been concerned with here (Gardner and Lewis 1996).

There is also in HCI/human factors literature any number of papers that argue for theuse of ethnography ‘outside’ anthropology and ‘outside’ traditional anthropologicaldomains. However, the kind of ethnography that should be practiced ‘outside’anthropology is not something that should be left to, for example, engineering to sortout for themselves. If we do want to improve ethnographic practice within the humanfactors community, we can no longer limit ethnographic work to studies of end-users.If we want to produce knowledge designers and developers with value and be able toexploit, we will have to carry out the same kind of studies ethnographers have producedfor industry for almost 20 years, but we will include our clients/customers among those westudy. In fact, what we have presented here is a first sketch of the kind of client/customerresearch ethnography can produce.

It is no longer enough to argue any more to that ‘all’ developers and designers have todo is take ethnography ‘seriously’ (Anderson 1994). The issues Bader and Nyce (1998)outlined will not go away even if engineers become more familiar with the concepts andmodels that inform ethnography. The interpretive burden has to rest on the ethnographersthemselves. Amongt the original commentary to the Bader and Nyce (1998) paper, we findthat Dillon (1998, p. 16) comes closest to what is described in this article by noting that

to accelerate matters we might reconsider some of our own assumptions and methods as socialscientists before asking other communities to reconsider their world view,

a recommendation that we, adopt: from even the brief sketch presented here of theengineer’sWeltanschauung, it should be clear just how refractory, if not impossible, strong,interpretive ethnography must seem to most of ethnography’s customers.

The translation and interpretation of different social orders is what has informedethnography for more than a century and a half. To adopt the kind of ethnography arguedfor here will of course raise any number of issues related to power, control and legitimacy.Any serious critique of a standard research method will raise issues of this kind. Howeverif the ethnographic method is going to produce the kind of yield its advocates believe it iscapable of delivering to industry, it is time for us to reconsider the scope and directionethnography has taken in the human factors community. It is time to try to apply theethnographic lens fairly and equitably, and for once try to understand our clients/patronsas well as we do end-users. This new ‘turn’ in ethnography could enrich what we all do inthe human factors community both analytically and pragmatically.

In the discussions that followed Bader and Nyce’s (1998) paper, valuable commentswere provided by Rosson (1998), Dillon (1998), Bowker (1998) and Simonsen and Kensing

Theoretical Issues in Ergonomics Science 11

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

(1998), as is obvious from the quotes used in this article, and the level of retrospective

concurrence demonstrated. Nevertheless, none of the commentators cross the ‘T’ and dot

the ‘I’, and conclude that we, first, need a much improved understanding of engineering

epistemology, which we suggest can be provided by ethnography. Furthermore, none of

these authors concluded that ethnography, perhaps unilaterally, is what needs to change if

knowledge transfer from one community to another is to be more successful.Is this a feasible solution? The answer is yes, because the end-point of ethnography

traditionally has been to understand what other cultures and communities value and why.

Further, to understand a community or culture to the extent that effective communication

can take place between them has been the raison d’etre for anthropology and ethnography

since the early nineteenth century. Given this, one could legitimately raise the question of

why the ethnographic direction has not ‘doubled’ before now, to help make ethnographical

data more intelligible and useful to engineers and designers/developers.

7. Conclusion

What at a first glance may be considered to be a problematic issue for ethnography and its

practitioners can in reality be a significant opportunity. Rather than ethnographers

limiting themselves to the traditional project in HCI/Human Factors, i.e. the study of a

particular tribe of users, we argue here that the ethnographic project needs to be expanded

to include a study of those who have to make sense of and utilise the results. We need to

understand this second tribe, as well as we need to understand the first. To achieve this, we

suggest that we need an improved understanding of the very basic nature of engineering,

and the corresponding epistemology of engineering practice. On this foundation, we need

to appreciate how we, as social scientists, and our science fit into this paradigm, and how,

on this background, ethnographical knowledge and results can add value to the practicing

engineering community. This is how the epistemological gap between ethnography and the

engineering and design communities can be overcome. The engineering and design

communities do not have the skill set to make sense of and reinterpret for others lay

artefact and knowledge requirements. Not only is this enterprise that ethnography has

historically been tasked with: it is its prime purpose and analytical, empirical strength.

Acknowledgements

The authors thank the anonymous reviewers for their contribution to this article: their comments,and the revisions caused by them, have undoubtedly served to improve and focus the studypresented. The contribution of Region Vastra Gotaland has partly financed the writing.

Note

1. Organisational and institutional factors can impinge on IT design and development cycles.While there is much anecdotal evidence that confirms this (see for example Kidder 1981), thesefactors, like epistemological differences, have not received much attention from scholars.One exception is Grudin’s (1996) discussions (Grudin and Markus 1997) on how these variablesare informed by and are responses to competitive pressure within and outside a firm.

12 E.S. Petersen et al.

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

References

Aaby, A.A., 2004. The philosophical foundations of software engineering [online]. Available from:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.59.7556&rep=rep1&type=pdf [Accessed 10

Nov 2009].Anderson, R.J., 1994. Representations and requirements: the value of ethnography in system design.

Human-Computer Interaction, 9 (3), 151–182.Bader, G. and Nyce, J.M., 1993. When freedom of choice fails: ideology and action in a secondary

school hypermedia project. National Association for the Practice of Anthropology (NAPA)

Bulletin, 12 (1), 66–72.Bader, G. and Nyce, J.M., 1998. When only the self is real: theory and practice in the development

community. Journal of Computer Documentation, 22 (1), 5–10.Bella, D.A., 1987. Engineering and erosion of trust. Journal of Professional Issues in Engineering,

113 (2), 117–129.

Bowker, G.C., 1998. A room with a view. Journal of Computer Documentation, 22 (1), 11–13.Busby, J.S., 2003. Mutual misconceptions between designers and operators of hazardous installations.

Bath: University of Bath, Department of Mechanical Engineering.Cuadrado-Gallego, J., et al., 2007. Epistemological and ontological representation in software

engineering. Paper presented at the international conference on computer science 2007.

Dekker, S. and Nyce, J.M., 2004. How can ergonomics influence design? Moving research findings

to future systems. Ergonomics, 47 (15), 1624–1639.Dillon, A., 1998. Cultural analysis and what designers need to know – a case of sometimes too

much, sometimes too little, and always too late. Journal of Computer Documentation, 22 (1),

13–17.

Ferguson, E.S., 1992. Engineering and the mind’s eye. Cambridge, MA, USA: MIT Press.Forsythe, D.E., 1999. ‘‘It’s just a matter of common sense’’: ethnography as invisible work.

Computer Supported Cooperative Work, 8 (1–2), 127–145.

Gardner, K. and Lewis, D., 1996. Anthropology, development and the post-modern challenge. London,

UK: Pluto Press.Grudin, J., 1996. The organizational contexts of develpment and use. ACM Computing Surveys,

28 (1), 169–171.Grudin, J. and Markus, M.L., 1997. Organizational issues in development and implementation

of interactive systems. In: M.G. Helander, T.K. Landauer, and P. Prabhu, eds. Handbook

of human-computer interaction. 2nd ed. Amsterdam, The Netherlands: Elseveier,

1457–1474.Gulliksen, J., Boivie, I., and Goransson, B., 2006. Usability professionals – current practices and

future development. Interacting with Computers, 18, 568–600.

Holloway, C.M., 1995. Software engineering and epistemology. Software Engineering Notes, 20 (2),

20–21.Holloway, C.M., 1996. Epistemology, software engineering, and formal methods [online]. Available

from: http://shemesh.larc.nasa.gov/people/cmh/epsefm-tcabst.html [Accessed 17 Jan 2009].Kerr, E.T., 2008. Engineering archetypes [online]. Available from: http://edinburghepistemology.

wordpress.com/2008/12/02/engineering-archetypes/ [Accessed 10 Jan 2009].Kidder, T., 1981. The soul of a new machine. Boston: Atlantic-Little, Brown.Koen, B.V., 1985. Definition of the engineering method. Washington, DC: American Society for

Engineering Educations.Koziolek, H., 2006. The role of experimentation in software engineering. Trustworthy Software

Systems, 1 (1), 11–33.

Kranakis, E., 1997. Constructing a bridge: an exploration of engineering culture, design and research in

nineteenh-century France and America. Cambridge, MA, USA: MIT Press.Kuhn, T., 1962. The structure of scientific revolutions. Chicago: University of Chicago Press.

Lassiter, L.E., 2005. The Chicago guide to collaborative ethnography. Chicago, USA: The University

of Chicago Press.

Theoretical Issues in Ergonomics Science 13

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010

Lutzhoft, M. and Nyce, J.M., 2008. Integration work on the ship’s bridge. Journal of Maritime

Research, 5 (2), 55–70.

Neill, C.J. and Laplante, P.A., 2003. Requirements engineering: the state of the practice. IEEE

Software, 20 (6), 40–45.

Neill, C.J. and Laplante, P.A., 2004. The demise of the waterfall model is imminent and other urban

myths. Game Development, 1 (10), 10–15.

Nyce, J.M. and Bader, G., 1995. To move away from meaning: collaboration, concensus and work in

a hypermedia project. In: M. Shields, ed. Work and technology in higher education: the social

construction of academic computing. Hillsdale, NJ, USA: Erlbaum, 65–87.Nyce, J.M. and Bader, G., 2002. On foundational categories in software development.

In: Y. Dittrich, C. Floyd, and R. Klischewski, eds. Social thinking: software practice.

Cambridge, MA, USA: MIT Press, 29–44.Nyce, J.M. and Lowgren, J., 1995. Towards foundational analysis in human-computer interaction.

In: P.J. Thomas, ed. The social and interactional dimensions of human-computer interfaces.

New York, NY, USA: Cambridge University Press, 37–47.

Petersen, E.S., 2010. User centered methods must also be user centered: a single voice from the field.

Goteborg: Chalmers Technical University.

Rasanen, M. and Nyce, J.M., 2008. Rewriting context and analysis: bringing anthropoloty into HCI

research. In: S. Pinder, ed. Advances in human-computer interaction. Austria: InTech Education

and Publishing, 397–414.Rosson, M.B., 1998. Synthesizing diverse perspectives. Journal of Computer Documentation, 22 (1),

18–19.Simonsen, J. and Kensing, F., 1998. Make room for ethnography in design! Journal of Computer

Documentation, 22 (1), 20–30.Vaughan, D., 1996. The challenger launch decision. Chicago: The University of Chicago Press.

Vincenti, W.G., 1979. The air-propeller tests of W.F. Durand and E.P. Lesley: a case study in

technology methdology. Technology and Culture, 20, 712–751.

About the authors

Erik Styhr Petersen holds the current position of Deputy Director of Technology at Lyngsø MarineA/S, Denmark, and the mother company SAM Electronics GmbH, Germany. He is responsible for anumber of management functions relating to the company’s technology base, as well as for thedevelopment of usability across the range of navigation and automation products. His previousexperience includes participation in, and management of, internal and external projects relating tousability and user centered design of marine electronics, the latter including ATOMOS, ATOMOSII, DISC, DISC II, ATOMOS IV. Erik Styhr Petersen holds a BSc in Naval Architecture and a Lic.Eng. in Usability and User Centered Design.

James M. Nyce (1987 PhD Brown) is Associate Professor in the Department of Anthropology, BallState University, Muncie, IN. Nyce studies how information communication technologies emergeand are used in complex workplaces and organizations. A docent (informatics) at LinkopingUniversity, Nyce has been visiting professor in military technology and war science at the NationalDefense College, Stockholm, 1998–2000 and 2005 to present. He is also Adjunct Associate Professor,Department of Radiology, Indiana University School of Medicine and visiting Professor in LundUniversity’s Master’s Program in Human Factors.

Margareta Lutzhoft is a master mariner, trained at Kalmar Maritime Academy in Sweden, and sailedfor 13 years in Swedish ships. After leaving the sea, she studied for a Bachelor’s degree in CognitiveScience and a Master’s in Computer Science. In December 2004 she received a PhD in Human-Machine Interaction. She presently works as Associate Professor at Chalmers University ofTechnology, leading the Maritime Human Factors research group at the Department of Shippingand Marine Technology, within the Lighthouse competence centre.

14 E.S. Petersen et al.

Downloaded By: [Lützhöft, Margareta] At: 08:21 19 October 2010