What is extreme text analysis?

Extreme Text Analysis (XTA) is a way of doing computer assisted text analysis in pairs that borrows from the Extreme Programming (XP) software engineering methodology. At the moment ETA is undertheorized, which is why we call it a "way" not a methodology. In trying to do XTA in a series of openly documented experiments we are trying to work out the way, determine whether it is a useful method and see if it might work for research and learning.

How does it work?

The idea is simple. Two people do text analysis together with only one person on the computer and the other directing and commenting (and typing a meta-narrative on another computer). This means that all decisions have to be discussed and negotiated which means that one is forced to reflect on what one is doing, which was the point for us. It takes longer, but you get a better result and you are forced to reflect on what you are doing. Some features of our XTA practice:

• We set aside one or two days to do this in the TAPoR lab at McMaster.
• It takes two people both present to do this. If one begins to do tasks without the other it is no longer XTA.
• One of us did the text analysis as if researching a text interpretation question. This is the text analyst role.
• The other directed what should be done and documented how the technology and research practice was going. This is the director of reflection role.
• We switched roles between experiments.
• We tried to avoid dividing text analysis tasks so that we could get more done. The idea of XTA, as frustrating as it may seem, is that all the text analysis is done by one person in conversation (only) with another.
• This appears to take longer than one person just doing it, but the point is the reflection on how to do it and the documentation of what worked and didn't.
• We restricted ourselves (mostly) to using the TAPoR Portal in order to test it and document its limitations and opportunities. We were constantly discussing how it should work to enable text analysis research and what tools we need.

In effect one of us was pretending to be a scholar using text analysis to answer a humanities question while the other was free to observe and document how well the technologies and methods worked. One of us was focused on doing and documenting the textual question while the other was looking at a computing question.

Outcomes of Extreme Analysis

Extreme Programming is a methodology that is supposed to be more responsive to client needs and better documented in the sense that the user requirements emerge in a dialogue rather than being specified (and frozen) at the outset. Extreme Text Analysis, as we practiced it, was more a reflective practice, that used experiments in small text analysis to reflect on methodology and technology. Our XTA could evolve into something more like XP, where the point was the text research, but for the moment the experiments were kept small and manageable in order to look at the life-cyle of a text analysis project. One way to see this is to look at the layers of outcomes we imagined when starting these experiments:

1. A short web essay on one or more texts. The outcome of an scholarly text analysis project is usually some form of research paper that reports back on the original interpretations drawn from texts. Such a document is not about methods or technology - it should be the result of a research practice that can be shared with the interpretative community. It should be about something like "what do Obama and Wright have to say about race in America?" not about "how to text analysis tools support textual research?" This is the goal of text analysis research - to develop tools that support inquiry into the questions that matter to us where there are electronic texts that can help. This is written by the text analyst role.
2. Research resources including the electronic texts and text analysis results that support the conclusions. These are paraphenelia, notebooks, traces, and transitional documents of research. Some of them might be shared so that others can recapitulate research and some not. In XTA our practice is to share so that others can understand and critique our experiments. More importantly, we are interested in the nature of these working documents and how to enhance their creation, collection, and use in the research process. In particular the Research Log where one records results for transformation into an essay or publicaiton. Obviously, in other situations these documents might be inaccessible due to intellectual property issues or suppressed because they are working documents. This is written or gathered by the text analyst role, though, to be honest, the director role helped in our actual experiments. To be pure, the director shouldn't do any of the analysis and essay writing so that he/she can reflect on how it is going, but in reality there are dead moments while waiting for detail tasks when the director can help.
3. XTA process documentation is the transcript of the XTA process as it happens. It is a "meta" document in the sense that it documents how the text analysis is working, not the progress of the textual interpretation. If the first two documents are what an interpreter would produce with (or without) text analysis, this is a document for theorizing text analysis as a methodology. It is reflecting on the practices, tools, and methodologies rather than the interpretative question for which the tools are support. This is written or gathered by the director role.
4. Reflections on text analysis are the outcomes of such a layered process. The point of pairing someone who does it with someone who reflects is to better understand the research process and the opportunities for computer support. These reflections can take the form of better documentation, better tools, reflective essays, new directions, or frank recognition of failure. This document itself is such a reflection. These are written by both roles, and, for that matter, anyone else who wants to try or comment on this process.

Bibliography

K. Auer and R. Miller. Extreme Programming Applied: Playing to Win Boston: Addison-Wesley, 2002. This book follows Beck's Extreme Programming Explained with "pioneer stories".

The methodologists say we should build software the way civil engineers build bridges, to pick one example. After all, they've been doing what they do for far longer than 'software' has even been a word. Using their approach will make us successful. ... As the British say, this is utter tosh. It's bunk. Let that sink in. ... Software is fundamentally different from physical sutff. It is expected to change. That's why it's called software. (Introduction, p. xxxv)

K. Beck. Extreme Programming Explained: Embrace Change Boston: Addison-Wesley, 2000. An introduction to Extreme Programming. Here is a quote from the Preface that explains the "extreme" in extreme programming:

XP takes commonsense principles and practices to extreme levels.

• If code reviews are good, we'll review code all the time (pair programming).
• If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
• If design is good, we'll make it part of everybody's daily business (refactoring).
• If simplicity is good, we'll always leave the system with the simplest design that supports its current functionality (the simplest things that could possibly work).
• If architecture is important, everybody will work defining and refining the architecture all the time (metaphor).
• If integration testing is important, then we'll integrate and test several times a day (continuous integration).
• If short iterations are good, we'll make the iterations really, really short - seconds and minutes and hours, not weeks and months and years (the Planning Game). (Preface, xv)

W. Cunningham. WikiWikiWeb: Extreme Programming. The first wiki - dedicated to Agile Processes including Extreme Programming. Here is a quote from the page from Kent Beck.

What really matters?

Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters?

1. Coding. At the end of the day, if the program doesn't run and make money for the client, you haven't done anything.
2. Testing. You have to know when you're done. The tests tell you this. If you're smart, you'll write them first so you'll know the instant you're done. Otherwise, you're stuck thinking you maybe might be done, but knowing you're probably not, but you're not sure how close you are.
3. Listening. You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You probably won't know this yourself, so you have to get good at listening to clients - users, managers, and business people.
4. Designing. You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise, you'll sink under the weight of your own guesses.

Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.

Wikipedia. Extreme Programming. A good overview of XP including a section on controversial aspects.

-- GeoffreyRockwell - 03 May 2008

---

Use this box to quickly add a comment to the page.