Verbal Communication
Jerry: Kramer, you’re never gonna be able to completely stop talking.
Kramer: Jerry, ninety four percent of communication is non-verbal. Here watch.
Kramer does some violent and hilarious miming; he ends up contorting his face and moving his lips so that you can make out somebody angrily saying “What are you talking about!?!”, followed by some crying).
Jerry: Well, what does this mean?
Kramer: Well it’s Frank and Estelle’s reaction of hearing about George’s man love towards she-Jerry.
(Seinfeld, The Cartoon, Episode 169; view the clip here)
Despite Kramer’s claims that 94% of communication is non-verbal, everyday practice teaches us that the main means of communication is still prevailingly verbal. Either face-to-face communication, or over the telephone, or through letters, emails, electronic and printed media, the communication occurs mostly through words, sentences, etc.
What does this mean in terms of technology? It basically drives home the fact that technology is text-based.
But isn’t this stating the obvious? Of course it is clear that all the documents, specifications, measurements, etc. are text-based. What’s the point in bringing this up, then?
Well, when it comes to information technology (read: software), things suddenly stop being so simple. Unlike other technological innovations for storing information (like paper), large majority of software legacy systems seems to shy away from text. There are a couple of reasons why historically we’ve ended up in such a mess.
Scarcity of Resources
IT industry has always been a very costly venture. The prices of hardware and software had, for the longest time, been at the premium. This created the scarcity of resources mentality that had been drilled into every software developer. Do more with less technical resources is the mantra that brought upon us such disasters as the Y2K fiasco.
Basically, since data storage availability was at the premium, software engineers were forced to bend over backwards in order to squeeze the last drop out of exorbitantly expensive auxiliary storage space. Thus, it was unthinkable when writing software in the ’60s, ’70s, ’80s, or even ’90s, to store the four digit year on disc. What an irresponsible waste of space! Two digit years will do just fine. And it will save us untold amount of dollars in unused disc space.
Similarly, any numeric values could be, via some engineering trickery, stored in a compressed format on disc. IBM mainframes are thus using packed, or binary-coded decimals. These (and similar) acrobatics allow them to save storage space.
Today, as the issues of data storage are bordering on trivial, such concerns are largely irrelevant. We can now relax and liberally store four digit years, as well as decimal values in human-readable form.
The scarcity of resources nevertheless persists, simply as a force of habit. And, as we will see shortly, it is causing a lot of friction.
Strong Typing
Software development requires exercising considerable discipline. At the same time, on average, average organizations will employ average individuals. Not surprisingly, such average developers may lack the stringent discipline required to deliver bullet-proof products.
Because of these constraints, strongly typed programming languages were introduced. This innovation ensured that most of the sloppy thinking that may occur at the at the low level gets caught and reported during compile time. This furthermore ensured that no workable program with grossly incorrect handling of data ever gets produced.
But, it also created software products that are counter-intuitive and that require considerable acrobatics when it comes to data transformation. Again, text, the most natural form of data and information, got replaced by some highly abstract engineering constructs.
The Information Flow
The information reaches end-users in the form of text (there may be some accompanying non-textual information, such as images, graphs, audio, video etc., but still the majority of information is in most cases textual). The users read it, parse it, and make decisions based on the information they had just processed.
Sometimes, the decision includes modifying the information presented to them. Typically, all the modifiable information is in textual format. The users will modify/remove/add some text, and post it back to the server.
The above described information flow is very straightforward, and it would be natural to expect that software applications would very easily accommodate such flow. However, we find that in everyday practice that is just not the case. If we examine majority of software applications in use today, we will notice that they usually tend to engage in fairly elaborate set of acrobatics each time the information flows to or from the end-user.
This extraneous set of acrobatics influences the cost of delivering, and maintaining software products. If you ever get a chance to examine a typical Enterprise Java application that handles simple textual flow of information from the server to the end-user, and back from the end-user to the server, you’ll be amazed at the magnitude of acrobatics, muscle-flexing, and other completely non-intuitive activities that occur in the so-called middle- or business-tier. All these frantic activities tend to introduce an incredible amount of friction, thus dramatically raising the cost of delivering the solution.
Who Dictates That The Acrobatics Must Be Performed?
At this point, the question “who is the dictator here?” naturally comes to mind. There must be a good reason why we are expending so much energy and resources behind the scenes. Could we perhaps not simply deal with text instead?
The answer is, of course, “no”. We must perform all those acrobatics in order to serve the needs of the underlying databases. As heirs to the IT legacy of the bygone era, relational database management systems (RDBMSs) are very stringent beasts who tend to dislike text. Why? Because text is wasteful.
But isn’t is clear by now that we’ve reached the stage where auxiliary storage is practically unlimited? If so, who cares if text is not as compact as some other engineering inventions?
Well, software engineers care. They are still riding on the wave of scarcity of resources, and are kind of giddy on the power of their own inventions. To propose a text-only database solution would be sheer blasphemy.
Is Text-only The Way To Go?
If we agree that the majority of communication is verbal, then I’d say “yes”. Let’s focus on text. After all, almost all the relevant information we care about is either displayed on the screen as text, or printed on paper as text (with the notable exception of engineering diagrams).
But what about the RDBMSs? Well, in today’s IT topology, RDBMSs are only one among a number of players that get combined with other data stores. Most notably, there is an increasing number of XML-based data stores that mostly contain textual information.
So, if I implement an application that stores text-only data in a relational database that had a major portion of its brain surgically removed by me, would that enable me to allow for a simple flow of text? Well, not really, or, not unless I’m using the right tools.
The problem also exists in the strongly typed programming languages used for developing the applications. And these languages are still the most popular ones in today’s mainstream development culture. Because of the enforcing of the data types, text is again not desirable, and we’re once again forced to perform all kinds of situps in order to transform the text into its non-intuitive representation, and then back again into the plain text.
The Solution? Ruby!
I personally found that Ruby is the tool that can help me resolve the above described impasse. Ruby is the Smart Servant that understands my human bent toward plain text, and at the same time knows how to translate my text-based intentions to the underlying machinery. This match made in heaven allows me to easily maintain the desired level of verbal communication without worrying about translating all that mess into a machine-readable form.
With Ruby (and Ruby on Rails, of course), I can have textual information flow from the data store and, after being marked-up, shown to the end-users as plain text. Any changes that the users make, will travel back to the data store as plain text, so I don’t have to do any acrobatics in between.
Any derivative processing of the plain text (such as juggling of the dollar amounts, dates, percentages, you name it) gets performed by Ruby in the background. Now that’s what I call Smart Servant!