{'fraction_non_alphanumeric': 0.02813852813852814, 'fraction_numerical': 0.004329004329004329, 'mean_word_length': 5.29700272479564, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Ethnography re-engineered: the two tribes problem

Does ethnography have anything to offer to the engineering community or the computer development community? Theoretically, yes, it does. Ethnography can provide 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 find any discussion of commercial hardware or software products in which ethnography demonstratively played a decisive part, which has led some to argue that ethnography, as it is currently practiced in the computer development community, 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 the development community. Journal of Computer Documentation, 22 (1), 5–10] raised this issue a decade ago, and argued that ethnographic knowledge appeared to be largely unintelligible and inoperable to the computer development community. To date, this debate has not been taken much further, and the results of ethnographic research continue to be published in the HCI/Human Factors literature. The issues Bader and Nyce raised a decade ago have however not gone away: to what extent can ethnography make a practical contribution to the computer development community? This article picks up this discussion, re-examines the original arguments and commentary, adds a Koenian view of engineering epistemology to the analysis, and concludes that we appear to require a much improved understanding of engineering epistemology, to support interdisciplinary communication. Building on this foundation, what may furthermore be necessary is to perform an ethnographic operation twice, not just once: essentially, it is argued, it is necessary to build a kind of ethnography that takes the ‘interpretation’ of research findings to one’s clients as seriously as it does the interpretation of what goes on in a particular, ‘targeted’ workplace for end-users. By providing this kind of ‘double’ translation and interpretation, it would be possible to ‘deliver’ ethnographic findings to the engineering communities in a form they find intelligible, simply by doing what ethnography does best: the discovery and interpretation of what is taken to be self-evident and logical.