Writing software is hard, particularly when the schedules keep programmers' “nose to the grindstone;” every so often, it's important to take a breather and look around the world and discover what we can find. Ironically, what we find can often help us write software better.

In an issue devoted to “emerging technologies,” it seems only appropriate to discuss the role of old bits.

Not too long ago, a friend of mine working for a startup was evaluating a search engine. Not “search engine” like Google or Bing, but “search engine” like Lucene or Solr or ElasticSearch, for use on the startup's website, to be able to search for data stored in documents and databases not normally made easily available to those page-crawling search engines. In of itself, the thing she was evaluating wasn't important - it was the criteria by which she was doing the evaluating that was the issue.

“I find myself looking at the documentation, sure, but I also find myself looking at when was the last time somebody checked in to the codebase? If it's been more than a year or so, that strikes me as a reason not to really spend a lot of time on it - if they're not still updating it, then pretty clearly, the momentum is lost and I shouldn't get too closely attached to it.”

This got me thinking - what is it about software that convinces us that it has to stay in motion in order to be useful? By definition, any time a software developer introduces a change into software, even the most trivial, we have to re-test the entire thing (which, by the way, is generally the best reason I can think of to have a comprehensive automated unit test suite) before we know that the software is ready for production. In fact, several companies I know hold it as a golden rule, based on their experiences with doing things to the contrary - nothing goes out onto the production site before it's been tested.

So why are we so fond of change? And, to be clear, I'm not advocating that we should all go back to C or COBOL or FORTRAN or PL/1 or some other “golden oldie” language under the rule that “if it was good enough for my daddy and his daddy before him, it's good enough for me.” We learn a lot from experience, and comparing C# to C clearly shows a lot of progress and understanding.

And yet, it seems intuitively obvious that this roller coaster has to come to a stop at some point. Look at what's been happening in the relational database world, for example. If you can find one person who can describe a substantive change between SQL-92 and SQL-99, not to mention between SQL-99 and SQL-11 (the most recent version), much less between SQL-92 and SQL-11, I'll buy you a beer. (But to be fair, please make sure it's a person who doesn't work on an RDBMS product or writing the spec - I mean somebody who just uses the thing. Any of them.)

It's fair to say that relational databases are… well… done.

Emergence

In an issue dedicated to “emerging technologies,” it's easy to overestimate the impact that these new toys will have on our industry. Remember when objects were new? “Tinker toy programming” was the term du jour, since objects meant that all the important software in the world was going to be simply “assembled like tinker toys;” pull an object off the shelf, glue it to another object off the shelf, take those in turn and glue them to some other objects, and so on.

(Oh, I suppose I should mention that tinker toys were what we played with before Legos took over the universe. Just in case.)

At the time, objects were clearly the path forward, the thing that everybody pointed to as the revolution in software that would make all our dreams come true. Companies formed around providing those off-the-shelf objects, dreams were constructed via frameworks, and even operating systems were jumping onto the object approach, either from scratch (as BeOS was), or by attaching object-oriented principles to the current existing bits (as OS/2, Windows, and a few others were doing). Objects were everywhere, they were hip, they were big, and they were cool. What was to discuss?

And yet, even at the same time that people were gushing over objects and talking about how object-oriented was going to revolutionize everything, one man was kinda going the other way.

“I invented the term object-oriented,” said Alan Kay, “and I can tell you for a fact that C++ was not what I had in mind.”

Fast-forward a decade or so, through the Java and C# worlds, and we can see a little bit better what he meant: that Smalltalk (his invention) and C++ (the ancestral father of both C# and Java) come at the approach of objects entirely differently. One comes to it through dynamic types and messages dispatched in a very loosely-based fashion, the other comes via methods invoked through dispatch tables and type systems known ahead of time. Each has its strengths, and each has its weaknesses, but…

...but you couldn't have told this to anyone at the time.

Done

Many years ago, when .NET was first introduced, somebody asked Don Box if COM was obsolete. As is typical of Don, his response was terse and thought-provoking: “COM isn't dead. It's done.” Predictably, lots of people took offense at that last part - my presumption being, they thought that “done” meant “dead.”

Similar kinds of sentiments are emerging today around the database story with the rise of the NoSQL databases: CouchDB, MongoDB, Neo4J, Cassandra, Riak, Redis, and the rest. Some within that community are arguing that the relational database is obsolete and needs to be trashed entirely.

And, to be honest, though I don't count myself as one of them, I do think we are finally only now emerging from a “database Dark Ages,” one in which the only acceptable way to store data was the relational model in much the same way that back in the 1400s the only acceptable Church was the one headed by the Pope in Rome, and how the rulings of that Church took precedence over everything else. To suggest that the earth rotated around the Sun was grounds for burning at the stake; to suggest that the data model might not be best stored in a relational database was grounds for excommunication.

And yet, let's not replace one heresy with another. The relational database describes a good model for relating data bits in a structured way, along with a powerful language for extracting and discovering data.

Similar kinds of things are being said about the desktop PC, too, that “the PC is dead,” a two-fold indictment, it seems, since lots of people use “PC” to mean both “desktop mouse/keyboard/monitor-based computer” and “Microsoft-based computer,” as opposed to the hip and cool and happening Android and iOS tablets/slates. Metro is being sold to the world as the new Windows because clearly, the world is moving on past the desktop PC.

And yet, allow me to ask, how many of you have actually tried to code on a slate? Not for just a few minutes, I mean for a whole day? Or, if you prefer, since not everybody writes code for a living, just written a letter? Or an article? I've done both, and let me just say this: I'm not doing away with my laptops anytime soon.

Done and...Done

Within the agile community, there is a growing meme that talks about “done meaning done,” in the original sense of the term: the product is finished, there's no more work that needs to be added to it, because it meets all the needs that its customers and clients ask of it.

When is a language done? When is a data-access layer done? When is a search engine done? Before we rush to adopt the next new thing, perhaps we should establish for ourselves what we want out of a “thing,” and what “done” for that “thing” really means.

And when it's done, will we embrace it, or abandon it?