electronic archaelogy

In chapter 7 of his book Practical C Programming Steve Oualline describes the most fundamental problem any software developer has to deal with: Electronic archaelogy. In his own words:



Electronic archaeology is the art of digging through old code to discover amazing things (like how and why the code works).

Unfortunately, most programmers don't start a project at the design step. Instead, they are immediately thrust into the maintenance or revision stage and must face the worst possible job: understanding and modifying someone else's code.

I remember Software Engineering as being the most boring class I had as an undergraduate. While the course content had enough material for several trivia nights at the CMM Café it remained, like most of the stuff we learned, purely academic and non-pragmatic. You can consider yourself lucky if you are involved in a project right from its inception and design. In the most general case, you will end up nursing a Child from Hell and patching leaky holes (bullet wounds) in the codebase (soldier's body after war). This can be quite frustrating. Such an experience of pragmatism conflicting with principles can leave you a scarred schizophrenic developer.

The antidote: Prayer. Pray that the code you end up dealing with and modifying has been written in your favourite programming language. This is not the right time or place to learn a new language...the wrong way. But then, most people learn a new language the wrong way the first time. Undoing that and correcting their impressions takes a lifetime (what they refer to as 'years of experience' in your résumé).