Language Wars - Whatever Works!
Friday, December 16, 2011 at 3:13PM Over the years one of the most common and perhaps most often misunderstood practice is that of technical professionals to have debates on technologies. The technologies in question are typically ones that each person has had extensive or perhaps not so extensive experience with. Most of the time these discussions are taken in the proper spirit of exchanging insights and improving one's education. However once in a while, the discussion turns into verbal arguments about how technology A is "better" than technology B. To most technical individuals this is part of the territory. However business users and similar non-techies tend to see these debates as highly disconcerting. What are they to make of experts that they respect not reach a consensus about which technology would be proper to use for their business problem.
In my experience it is much less an issue of what technology to be used as opposed to what is the problem that needs to be solved. The age old wisdom of "use the right tool for the right job" comes to mind. In many cases arguments about which database to use still persist in spite of the diminishing return in terms of identifying actual hurdles to solve a problem. A nice recent example came to mind about MySQL vs. Oracle RDBMS. The fact that both products are now supported by the same vendor (Oracle) and both have excellent track records for many large deployments would to most people seem to end the debate on which to use. Yet within many organizations the war still wages. Generally what I see is typically around length of experience or perhaps even age. Most older/experienced professionals tend to gravitate towards Oracle having a veritable treasure trove of industry best practices within past organizations on it's use. On the opposite side, younger/equally experienced professionals who have exposure to different technologies such as Ruby-on-Rails, PHP, etc. have mostly used MySQL. They like the usability, the ease-of-administration, and the elegance of how the technology has worked it's way in many times seamlessly with their toolkits such that others solutions seem cumbersome in comparison. In the end either database is more than likely able to address pretty much any size scale of problem for an organization, however the arguments wage.
These arguments for the most part are not really based on any technical merit. Instead they are based almost exclusively on pre-existing viewpoints and internal politics. For instance building on the MySQL and Oracle example, in many large (and not so large) organizations IT decision makers tend to classify anything for "production, customer facing" to be Oracle with MySQL tagged as "experimental, prototyping". When I inquired about this curious categorization it came down to a perception that the Oracle RDBMS was more "robust/scalable" or had a "better track record" for mission critical applications. Even in spite of pointing out examples such as Facebook or Sabre Holdings the IT leadership continued to stress the use of Oracle. I even had a nice "sit down" session with an executive VP of technology who advised me that even "mentioning" MySQL would cause issues from the CTO and other members of the executive staff. Unfortunately these sorts of encounters far more often than not.
From a technical standpoint pretty much any technology can work to resolve a problem: Java, Ruby, PHP, Scala, Erlang, C, C++, Oracle, MySQL, Postgres, Hadoop, MongoDB, whatever. However no matter the technology whether Open Source or vendor-provided, it requires a commitment from the business to adopt it, own it, learn it... basically invest and believe in it. This is tremendously foreign to many companies who tend to see their legacy applications as necessary evils in doing business not as strategic tools for competitive advantage. While many companies see the use of technology as the domain of high-tech companies, the truth is that many organizations in many different industries use technology to solve problems from auto manufacturers, to supermarkets, to dentists, heck even your local pub probably has a computer system of some kind squirreled away allowing their servers to place orders to the kitchen.
Generally speaking from my experience organizations that tend to not trust technology are really not trusting their internal partnership with technical departments. Now I will admit that a falling out in a relationship is hardly caused by one party but usually all parties, however generally I find that internal technology groups are having a hard time coping and adapting to the changing world around them and trying to meet the business demands. Again while there are many symptoms such as lack of education, out-dated implementation cycles, etc. the core issue is typically a lack of commitment and that starts from the top. Almost all proper working relationships have C-level leaders who are in agreement both publicly and privately with the business needs and strive to do the utmost to give them what they need. However C-levels that "have doubts" whether directly or indirectly carry themselves accordingly; project plans are padded, micro-management is taken up to "insure things run smoothly", requirements are not provided, etc. These views then travel down throughout an organization resulting in a very large cultural barrier in accepting let alone implementing anything necessary to meet business needs.
Language wars tend to be used as a scapegoat in almost all organizations as to why they are not getting what they want from their internal technology groups. Instead organizations need to understand what type of technology team they want/need (great HBR article on this concept) and then have the commitment to get there.

