I love Vernor Vinge’s concept of a “programmer-archeologist” (A Deepness In the Sky, he also coined “programmer-at-arms”) as someone who digs through the layers of existing systems to understand why and how stuff works.  I was reminded of this over the weekend, as I worked through some old code of my own and that from a bunch of other developers on DailyLit.

My exposure to “software archeology” goes as far as back as the first time I earned money from programming.  I was 17 and had just come back to Germany from one year as a high school exchange student in the US (Rochester, MN), where I was impressed by how everyone was earning their own money.  Since I thought I knew how to program, I looked for a job as a programmer.  My first job wound up being with a small company that was developing accounting software.  They were working on a rewrite of an “inherited” system that was written entirely in an early form of Basic which allowed variable names to be only 2 letters.  There were no comments anywhere in the code.  At the time, we wound up building a whole bunch of “archeology” tools, such as a cross reference generator.

From there I went on to work for Siemens developing some HR software while finishing school in Germany.  The job came about because the local Siemens branch in Nuremberg did not want to wait for the central IT department to get around to this piece of software and so hired a bunch of contractors instead.  I wrote a big chunk of the “training” module which kept track of ongoing education courses taken by employees.  This was in 1986 and I only recently found out that a heavily revised version of the training module is still in use today.

Since then I have seen many more examples of the longevity of code – and hence the need for programmer-archeologists!  Many development problems (including some obvious ones I was looking over this weekend) are caused by programmers new to a project not sufficiently understanding the structure and capabilities of the existing code.  As a result, they often write unnecessary code  or put unnecessary kludges in place.  They often do so without taking the time to figure out whether the old code is still needed at all, which means that even more code accretes for future programmers on the project to dig through.

My conviction now is that it is as important a skill to be able to read and understand code as it is to write it.  As result, I believe that any developer interview should contain at least a couple of code reading exercises.  Ideally, these are integrated with some other problems, e.g. “extend this to do xyz."  I can’t wait until I see the first actual job posting for a "programmer-archeologist.”