Rust?

Before Borland's new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.
Joel Spolsky, Joel on Software

The Case Against Q

I just finished reading Mark Goodacre's The Case Against Q.

What strikes me first is this: Given that two examples of writing share substantial features of wording and order, the prima facie conclusion is that the author of one work knew the other. Any other supposition is multiplying entities and must bear a high burden of proof and the wrath of William of Ockham. Does Q pass the test?

The funny thing about Q research is how much of it resolves to - "well, I wouldn't have written it like that so how could Luke?" After indulging in a review of Greek verb forms, invariably a scholar will claim that Luke would have to have been a "crank" or "unstable" to have redacted Matthew in such a way. Is this really all it comes down to? I have yet to read a comment questioning Q's motivation or mental stability and yet Luke is second guessed continually.

In his book, Goodacre describes how the Q-ists will divide the double and triple tradition material into "Q", "Mark-Q Overlap" and the "Minor Agreements" and then declare that you are not allowed to analyze the material as a whole. Aside from enjoying the spectacle of an epicycle introduced to address each new difficulty, I was reminded of the trends I see in my own line of work.

In the software industry, someone is always writing a book which claims that their "new" way of doing things will eliminate all the nasty and unpopular parts of our jobs. Unfortunately, when you look more closely they have not eliminated anything, merely re-categorized the same - essentially unavoidable - tasks. Software engineers are supposedly trained in information theory which demands that a critical eye be kept on the overall information content of a system. Sadly, like a fundamentalist kicking the tires on a used car, developers all too easily compartmentalize the principles of actual programming and that of managing the project.

In much the same way, by dividing the Luke-Matthew material in to discrete piles, it seems that biblical scholars can indulge in word counting and the minutia of Greek grammar while mistaking their man-made framework for reality itself.

Early on in The Case Against Q, Goodacre describes how the reputation of Q skeptic Michael Goulder has suffered because of his tangential claim that the author of Matthew's gospel probably created much of his unique material himself. On reading this, my little heart went pitapat! This is an idea I have been struggling with for some time. How exactly do we know that the Evangelists were not making up stories/sayings/parables to suit their aims? They certainly felt free to rearrange and modify the material in their sources as they saw fit. What kept them from stepping over the line and creating pericopae from whole cloth? I realize that individual elements can be attested through other sources suggesting that they come from a shared pool of material, written or oral, but are there general guidelines for discriminating between sourced material and pure creativity? Is the appeal to Oral Tradition a pitfall that prevents us from seeing the true nature of the work?

All in all, Mark Goodacre's work has further convinced me that Q as a theory has become brittle in the last 150 years and is subject to challenge from Farrer's theory or perhaps an insight we haven't even heard yet. Not that my opinion really matters... :)

I Need a Protocol Droid

"What I really need is a droid who understands the binary language of moisture evaporators." - Uncle Owen (Star Wars - The Real Movie)

Working in software development, I am continually inflicted with the latest open source scheme to transform the way we program computers. Someone in the organization decides that WidgetScam 2.1 will make waterfall, procedural, proprietary coding a thing of the past.

First off, there is some resume padding going on - software architects recommend to management the latest thing so that they can put it on their resume inspite of the fact that it will make the comopany no more productive or profitable. Relatedly, I believe that there is an ego factor whereby individual programmers need to feel like they are on the cutting edge. Me, I am old fashioned. I take pride in being a pretty good debugger and in being able to produce decent code that solves the needs of the customer (remember them?)

One amusing thing about this technological arms race is that we install all the new jars and dlls on our laptops and then keep programming the way we always have. Don't get me wong. I like programming in Java. It has some nice properties but Object Oriented Programming was sold as a complete paradigm shift in IT. Have you looked at any Java code recently? Most of it is dressed up C. Most programmers are writing procedural code in .java files. Of course, it works. It does what the specs require (most of the time) but there is no way that the advertised benefits of OO are going to realized.

So where are we now. I spend my days trying to install (and re-install, and re-re-install) software development tools on my cutting edge laptop all the while trying to balance my 64-bit vs 32-bit apps, the programs that require Java 1.5 vs those on 1.6 and the three different document repositories our company is using (Wiki vs network drive vs Alfresco). My industry is approaching the point where two systems will not be able to share information without an intervening layer that is more expensive, cumbersome and annoying than a protocol droid. Sometimes I wish we all just had R2 units. They aren't real shiny but they seem to get the job done.