Editorial Note: This post was written by Sarah Murray, one of the project directors, about the Stackenblochen approach to managing project data.
Like most normal people, I learned the most important organizing principle of my life and work from a skit on the Conan O’Brien show. Wisdom, thy name is STACKENBLOCHEN:
The skit shows a clip from a fictional German satellite tv program entitled “Stackenblochen”, in which contestants (in the skit, an amusingly frumpy middle aged lady) aim to arrange a set of knickknacks on a table at perfect right angles in a limited amount of time. Once the time is up, a military police looking fellow barges into the scene with an angle ruler and assesses the situation: in the skit he finds that the work is “NEIN STACKENBLOCHEN” and then a bunch of his goon buddies (and a large, gnashing-jawed goon hound!) join him in roughing up the contestant. End scene!
I guess the video is kind of dumb and now in the day of Infinite Internet Outrage some people might find it horribly offensive. When I first saw it I found it inexplicably hilarious. Anyway, STACKENBLOCHEN is a great word and I have adopted it as a theme for life, in the sense that everything is better if you try to get the figurative knickknacks on your figurative table to be at right angles to one another. In reality, this is just another way of saying that it’s important to be organized and tidy and to not let your life and work turn into a sloppy disaster area. I seriously do not understand how people live with thousands of random objects on their computer desktops or tens of thousands (I have seen it with my own eyes!) of unread emails in their inboxes! Or leave unwashed dishes in the sink, or – horror of horrors – not organize the beer in their fridge according to label color and alcohol-by-volume. Those, my friends, are classic examples of things being NEIN STACKENBLOCHEN.
So what does any of this have to do with archaeology? Anyone who has worked with archaeological data, especially in the ‘live’ context of data collection in a fieldwork project, knows that the information that you collect in a field project can be a difficult sort of beast to wrangle. In the planning phases of any project a lot of tricky work and thinking has to that go into deciding what kind of data will be recorded in the field, how to structure data entry forms and make sure fields will be entered consistently, and how different data will be related to its counterparts within the larger design of databases. But even when all that is thoughtfully done and optimized, there are inevitably problems that emerge during actual work in the field that result in sloppy or messy data being entered into your carefully constructed data design masterpiece. Some of these slop events relate to human error – most projects will have multiple people entering data at different times, and there is always going to be variation in the way that people spell unfamiliar words (I’ve seen at least 10 different spellings for “maquis” through the years!), describe features and characteristics of units, or organize their notes. People in the field tend to get tired and hungry and sometimes the glare on iPads used to enter data makes it impossible to see what you’re typing, and all that leads to mistakes. The machines we use to measure and record things often malfunction, or we mess up when we use them because we usually enter the field fresh off a year of teaching and writing indoors and forget their endearing quirks and special needs. Then there is the more fundamental issue of the archaeological record – it is kind of a wild animal in and of itself: we can try to make our units regular and record vegetation, geology, erosion, and other things that impact the data that we collect, but it is my experience that archaeological data almost always wants to be a little wonky. It resists being smooshed into the tidy data entry boxes with which we want to tame it.
Put another way, no matter how much you fight to make your data STACKENBLOCHEN, you will almost certainly always fail. Or anyway, I’ve never seen any such thing as a perfect set of field data. There are various ways that archaeologists can approach this problem.
The first approach is to accept that there is going to be some level of chaos in the data and come to terms with this state of affairs. If chaos is gonna chaos, you might as well just blast through with the fieldwork and let the chips fall where they may. A part of this attitude seems to entail a belief that the niggling details of the data just don’t matter too much: the big picture will be clear even if some small errors creep in at the edges, so there’s no need to really worry about how these can’t ever be fully eliminated.
Another attitude would be to enter into a fight to the death with data slop! Some noble archaeo-warriors refuse to accept that there will be any errors or problems with the data whatsoever. I admire this attitude: the belief that somehow through constant vigilance, errors and inconsistencies in the data can be entirely wiped out and eradicated, like a pestilence! Our data will then achieve the holy state of true Stackenblochen nirvana.
In my experience, neither of these (caricatures of) attitudes is really the right one. If you don’t accept that there are going to be problems with your field data, I think you’ll go crazy, because there are going to be problems. But I also think that if you relent in trying as best you can to make your data perfect, you’ll end up with a truly awful mess at the end of the day. As is often the case in archaeology, we basically have to try to strike a delicate balance between pragmatism and OCD. You have to both accept that at the end of the day your data won’t be perfect, but also strive every day to come as close as you can to approaching perfection.
I suppose this is an extension of one of the interestingly contradictory aspects of fieldwork. We’re supposed to be doing really systematic work and coming to conclusions based on ‘data’, kind of like a scientist would. But our data is almost always somewhat messy and archaeological interpretation is notoriously tricky – it sometimes feels like we basically never know anything for certain, no matter how hard we try. The evidence is just really hard to pin down: you can say some really specific things about a site, but once you start to generalize or move to a bigger conclusion, it’s hard to get the data to synch together into some coherent picture. Maybe this is why archaeologists get so excited when ‘real’ scientists show up and tell us that they can conjure things like ‘absolute’ dates or definite material proveniences.
Returning to the issue of the Stackenblochen, I thought about this video a lot the very first time I was given a position of any responsibility on a project: setting up and running the Total Station on an excavation. At first things were quite gravy: all I had to do was survey out the trenches, which meant a whole day out at site on my own, playing with an expensive machine, making squares, and pounding in rebar at the corners – pretty fun stuff. However, once the excavation started everything was totally crazy. There were a lot of active trenches, and every time one of them reached the end of a level they needed to get elevations before they could keep digging. I was running all over the place trying to keep everyone properly supplied with elevations and simultaneously keeping appropriate notes for my records. The physical work was pretty intense, and there was a lot of pressure. The excavation was a pretty special and sensitive transitional Late Bronze to Early Iron Age site, and folks in charge of trenches were taking a lot of care with the digging. Some of the passes were only a couple of centimeters deep, so if I messed up the station setup from one day to the next, the data would be a disaster, with lower levels registered above higher ones, or vice versa. If that happened, the ceramicists and other object analysts wouldn’t be able to piece together the whole picture for the publication, and on down the line to complete entropy! I had just graduated from college back then and the responsibility was overwhelming: everyone was depending on me, and I really didn’t want to screw everything up! Almost every day at the end of work – sometimes I’d work on site from 6am–8pm! – I’d sit with my computer and check every data point from the previous day to make sure it all made sense. If something was clearly wrong, I’d tuck my tail between my legs and go talk to the relevant trench supervisor immediately the next morning to figure out what had happened/what I had messed up. Usually we could figure out the problem and correct it without too much lost time.
This was an important lesson that I have carried with me for the rest of my career: if something is messed up, which it sometimes will be, it is infinitely easier to fix it right away than to try to reverse engineer some kind of fix days or months or years down the line. Mistakes with data are like missing persons cases: if you don’t solve it within 24–48 hours, the chances for a happy resolution diminish dramatically. All problems are easier to fix the sooner you get them dealt with, but I find this is very true of problems in archaeological data.
Along the same lines, one of my most important jobs at BEARS last summer was sitting down with the data at the end of the day every day, and again on the weekends. Although we had a great team and everyone did excellent work, it’s still good to have someone overseeing all of the material coming in from the field and the lab and ensuring that it is, in fact, Stackenblochen: checking to ensure consistent spellings in note entries, making sure that photos coming in from the lab all had labels and were in correct focus, etc.
It was certainly not always what I really wanted to be doing at the end of a long day of work, and nobody likes to be the military police goon with the angle ruler chasing down team members and telling them they have to redo some work because it is “NEIN STACKENBLOCHEN”! But the mistakes, big or small, that you catch that way, not to mention the mistakes you and your team avoid by being fastidious and tidy throughout, really can produce substantial problems for the analysis of the whole, especially if you let weeks, months, and years of them accumulate. Anyway, being the Stackenblochen enforcer isn’t the best, but it sure beats looking back at your data at the end of the season, or years later when you go to try to publish the whole thing, and realizing that it’s a mess and you have no idea what happened! At that point, the gnashing-jawed goon hounds are already at the gates!
