It's All Geek to Me!

« May 2006 | Main | August 2006 »

July 31, 2006

Blogging the Mahabharata: Introduction

"It contains all that is worth knowing; what is not in it is not worth knowing." So the ancient Indian sage Vaishampayan is reported to have said of the Mahabharata, widely acknowledged to be the longest epic in the world. It is arguably the most important text in the ancient Indian canon and contains, among other things, the Bhagavadgita, which, apart from being Hinduism's Bible-equivalent according to some, also packs a powerful philosophical wallop. The elaborate rituals of Hindu life may be ascribed to the Vedas, but the complex episodes and heroic personas that animate the Indian mythos live out their lives in the Mahabharata. Hardly any child in India--Hindu or otherwise--has grown up without hearing of this epic that captures the imaginations of billions, including me.

The Mahabharata (literally, "the great story of Bharat's line") has been the subject of a staggering amount of social, political and spiritual commentary in India. When compared with the Bible, it tends to omit details. Commandments, burnt offerings and uncleanness resulting from menstruation are not featured in its pages. Save for some explicit moralizing in the Bhagavadgita parts, the Mahabharata mostly features powerful characters whose choices and actions are nuanced and of ambiguous "goodness" and moral worth. The overriding message is one of realpolitik: dharma, or righteousness, must be upheld at all costs, even if it means betraying your clan, your relatives or even your own self. This sort of end-justifies-the-means outlook is deeply entrenched in the Indian collective psyche even today.

I was told the story of the Mahabharata several times in my childhood. Yet, not once have I viewed it as anything more than a story with occasional religious or prescriptive overtones. I've acquired most of my current critical reasoning skills in a secular, humanistic setting, after I left the milieu of my relatively religious family and community. Earlier, I viewed the Mahabharata as a simple clash between good and evil and as such, was uncritical of the established wisdom about its main characters. In recent times though, I've come to realize that as with any great epic, shades of gray that don't immediately meet the eye inhabit the Mahabharata as well.

Therefore, taking inspiration from David Plotz's Blogging the Bible project, I have decided to read the Mahabharata and blog about it. For starters, it would be a series of related posts -- hopefully one that would keep my readers coming back. It would make me read the Mahabharata in a renewed secular and humanistic light, divorced from its usual moralistic undertones. I hope to examine how some events of the Mahabharata continue to influence attitudes in India to this day. My writing will be less entertaining than Plotz's; I have much less to material to deride in the Mahabharata, because of its predilection towards skipping details that may seem absurd in modern life. For my reexamination, I will use this online full-text edition of the Mahabharata, if you want to read ahead. I hope that through this critical reexamination, I will end up loving a much-loved epic even more.

Watch this space.

Posted by Vishy at 11:24 PM | Comments (5)

July 13, 2006

Dynamic languages in the finance industry

Lisp, the ancient patriarch of computer languages, is derided as much in industrial circles as it is revered in academia. "What good is Lisp when you can't design real production systems with it?", its detractors have asked for a number of years. For all these years—multiple generations in the accelerated timescales of technology—such derision was hard to counter. Lisp and related languages were respected for the way in which they molded the thought processes of young computer scientists, but not for much else. And yet, now, if you look in the right places, Lisp and other languages that owe an intellectual debt to the Lisp programming environment are making a comeback. Recognized names in industry now employ functional and dynamically typed languages, including Python, Ruby, OCaml and Lisp itself as cornerstones of their operations. The financial services industry, one of the powerhouses of the modern economy, stands to profit immensely from this trend in particular. Let us see why functional and dynamically typed languages and the financial services industry can be such a great match for each other.

Before we proceed, there is a technical distinction to be made between functional languages and dynamically typed languages. Functional languages are exponents of a style of programming that considers any computer program as a function mapping input values to output values. On the other hand, dynamically typed languages, also known as dynamic languages, treat program objects differently in different execution contexts rather than requiring them to identify their type at compile time. Typically, dynamic languages erase the distinction between compile time and runtime because their compiler and runtime can be invoked in one go. The dynamic languages referred to above as being in vogue also support functional programming. Keeping this in mind, in the context of this essay only, we will use these terms interchangeably.

Computer applications in the financial services industry can be classified broadly into modeling, reporting and transaction-executing applications. Consider applications that model financial instruments and price them for the open market. Aside from sundry trading of stocks, bonds and other financial instruments, financial services firms profit by inventing new kinds of securities in-house and building armies of financial services experts around them. Once a new security starts trading in the open market, the technical infrastructure to model and price it also follows close behind. Currently, a financial services professional (FSP) must explain the financial concepts underpinning a new type of security to an applications programmer. The application programmer then produces an application that is aware of this new type of security by modeling it in object-oriented languages like C++, Java or C#. Building a compile-time type scaffolding around a new conceptual domain is not a trivial task. Most of the time, the sole purpose of such work is to pacify the compiler and has nothing to do with the conceptual domain of financial instruments.

Dynamic languages forgo strict compile time checking and view an object's type more as the set of operations it can perform rather than an inherent property of the object. Ruby, for instance, calls its dynamic typing 'duck typing', which comes from the adage 'If it quacks like a duck, it is a duck.' In other words, an object need only perform the operations characteristic of a type to qualify as an instance of that type. This feature turns out to be unusually handy in the financial services world. When modeling and pricing a complex security like an option on an option on a swap or a collateralized debt obligation (CDO) backed by another (also known as a "CDO-squared"), it's more important to know what behavior that security is capable of rather than ascribing it a meaningful type ahead of time. For example, the same set of operations apply to disparate kinds of derivative securities, regardless of whether they are based on an actual asset or another derivative. Correspondingly, in an object model representing these derivatives, it is more important to be able to put them in a collection and apply the same operation to them rather than care about the specific security from which they derive their value. A statically typed environment with compile time checks turns out to be more an encumbrance than a boon in such a situation. This is exactly where dynamic languages step in. They get out of the way of application developers by freeing them of strictly technical type-related concerns. Thus, they reduce the amount of work that goes into modeling a new financial product and save valuable application development time.

In fact, with the right choice of dynamic language, the line between FSPs and application programmers can be blurred, which brings us to the second benefit of dynamic programming languages to the financial industry. Time is easily the most valuable commodity in the financial services industry. For a company in this industry, a faster development cycle for financial computer applications could mean stealing that edge over its competitors in a hotly contested marketplace, where secrets don't stay secret for very long. The effort involved in developing financial software is split in a dichotomy between FSPs and technical-minded application programmers. Inevitable misunderstandings of requirements, along with other communication-related overhead, can quickly eat up valuable time in development cycles. Most dynamic languages today provide highly integrated development and execution environments, where it is possible to freeze the execution of a production application, introspect objects and their behaviors, and make changes to the system even as it is running. Back-and-forth communication between business units and application programmers can thus be greatly reduced. Additionally, today's dynamic languages are far easier to embed in larger applications than their statically typed counterparts. By using them, the application programmer can furnish the FSP with building blocks that let them program in a mini-language of their own. The FSPs do what they know best: modeling financial instruments; application programmers also sidestep any possibility of miscommunication by also doing what they know best: building good layers of abstraction.

Let us build upon the idea of abstraction a bit further to arrive at the third advantage of dynamic languages. An abstraction layer, it bears repeating, is a very powerful concept. For evidence of this claim, look no further than the copy of Microsoft Excel running on an FSP's desktop. Sometimes, the entire business of a financial services firm hinges upon Microsoft Excel. FSPs use Excel in a big way to get things done because they tell it what quantities they want it to calculate rather than how it should calculate them. This style of programming, called "declarative" programming, as opposed to the "procedural" variety application programmers are intimate with, is powerful because it operates at a higher level. It allows its users to ignore the details that don't ultimately matter. Functional languages are excellent at modeling an operation as a sequence of logical steps, where each step can be seen as transforming its input in some way before passing it along to its successor. Programs written in functional languages can inspect their own structure, modify it and generate other programs with astonishing ease. Imagine a "program of programs", a toolbox that contains other little programs to perform different kinds of operations. An FSP can model a workflow in this program of programs by dragging and dropping boxes, connecting them with arrows and defining how information flows across the boxes. Application programmers using visual development environments such as Visual Studio do this already when developing graphical user interfaces. The possibilities are essentially infinite if a high-level modeling approach such as this was adopted by FSPs by harnessing the power of functional languages.

Functional and dynamic languages are not appropriate for every kind of financial application. In cases such as trade engines, where raw performance is paramount, there is no substitute for the nose-to-the-ground approach of highly optimized programs written in traditional programming languages. Some firms may also be squeamish on multiple counts about using dynamic languages because most of them are open-source and don't have large corporations backing them. Yet, it is no coincidence that hedge funds and other financial services firms of the nimbler variety have built entire businesses around dynamic languages. It is ultimately poetic that the programming languages so well suited to an industry as dynamic as the financial services industry are also called dynamic languages.

Posted by Vishy at 10:49 PM | Comments (5)

July 12, 2006

Vishy's Indian English Dictionary: doubt

doubt. /DOWT/. A question asking for clarification. In standard English and American, the noun doubt is uncountable and refers to a lack of complete trust in something. Doubt may be expressed as simply as doubting someone's abilities or as profoundly as someone doubting their own religious faith. Not so in India. In India, doubt can be used as a countable noun. When a school teacher goes over an intricate concept in class, she invariably leaves some students with doubts in their mind about their understanding of the material just covered. Students ask her questions to get a better understanding of the concept and each such question is called a doubt. It is entirely normal to hear a statement like "I have just one doubt, miss" or "If you have any doubts before the exam tomorrow, come see me in the staff room". The doubts in the aforementioned sentences are not as much rooted in a lack of faith as in a lack of understanding. Attentive readers would have encountered the Indian English sense of doubt a fair bit on online message boards in threads started by Indians. Titles such as "Visual Basic .NET/Oracle doubt" are not uncommon for threads on programming-related message boards. It is my understanding that this sense is mostly prevalent in southern India, but I could be wrong on this count.

Posted by Vishy at 09:05 PM | Comments (0)

July 08, 2006

Google's future lies in its enterprise play

It has almost become too predictable. Every few months the traditional media and the blogosphere fall all over themselves trying to analyze the impact of the newest Web service to stream out of the Googleplex. Arguments, conversations and rebuttals rage for weeks around what else might be under drapes inside the sleek technology execution machine that is Google. Google's present success and future potential are widely acclaimed because of its impressive track record, the caliber of its employees and the quality and speed of its execution. It is clear that Google has changed the rules of the game in Internet business. Right from the inception of a new toy by Google—sometimes when it has just barely been released into the Google Labs playpen—speculation abounds on how it will revolutionize the market. However, the facts don't always bear out all the speculation. Apart from its core business, search, Google has made little headway in getting users to adopt its other services. With the induction of each new service, typically free of charge, into Google's portfolio, investors worry about how it will actually make money for Google. There is plenty of money to be made for sure if Google would only reexamine its strategies and wipe the dust off one: its enterprise play.

Corporate intranets and internal messaging systems for easier collaboration are no longer a rarity among medium-sized to large enterprises. Having said that, not all business processes within a company are automated yet. Consider the finance industry. There are a number of process inefficiencies such as manual verification and other labor-intensive checks surrounding the sale of practically any financial instrument. Due to the diligent access hygiene imposed by a number of regulatory requirements, several of these labor intensive steps are now done using electronic means. What used to generate a paper trail now generates an electronic trail of documents. Whether or not industry regulations require them, complex workflows and document management systems are gaining traction in other industries as well, notably healthcare. As the number of electronic documents floating around increases, so does the need to find them and organize them. Google has had a search appliance that solves exactly this problem. As physical processes increasingly get converted to their electronic equivalents, the information associated with them, which has remained 'dark' and unsearchable before, becomes searchable—analogous to the 'light matter' that makes up the visible Universe. The so-called dark Webs inside corporate firewalls continue to lighten. Google can focus a bit more on its enterprise offerings to capitalize upon this wave of change. To their credit, they have shown signs of noticing this swath of uncharted intranet territory by partnering with a number of organizations over a set of tools dubbed Google OneBox for Enterprise.

Google must also seek to expand another crucial arm of its enterprise play: mobile. Information workers are increasingly expected to have access to information while on the go. Currently, Google's mobile offerings outside the consumer space have been minimal. Consumers may not always choose the most Internet-enabled mobile devices for their personal use, but would use a highly Internet-enabled mobile device, such as a BlackBerry, if required to do so by their employer. This captive audience of users with powerful mobile devices is more than just a fertile testing ground for new Google mobile products that will later be targeted at consumers. Providing a viable mobile search solution that integrates well with that organization's search appliance would make Google's value proposition a lot more compelling.

We have so far considered only Google's existing offerings in the enterprise space; consider what new plays Google could make in this area. Google has its fingers on the collective pulse of the search habits of millions of users around the world. Let us suppose that one day it decided to mine all submitted queries that return less than a hundred results. During the course of this analysis, it is discovered that the phrases [walmart] and [health insurance] keep occurring together, although WalMart is not in the insurance business. How much would Walmart be willing to pay Google for the knowledge that its customers expect it to enter the healthcare industry? The real-life story of how HP got into the projector business bears more than a passing resemblance to the above scenario. A market research survey found that even before HP got into the projector business, it was being named as one of the top 3 brands of projectors in America. How about using the mounds of data Google collects to provide market intelligence to enterprises in the form of 'Zeitgeist consultancy services'? Think of an enterprise-grade, competitive intelligence version of Google Trends. Another piece of speculation recently seen in the press has been around Google's formidable infrastructure, which has proven equal to the challenge of Google's increasing user base. Why not provide comprehensive application hosting solutions to enterprises that wish to outsource their infrastructure entirely to a Google server farm?

Google has always allied itself strongly with the end user, the average Joe who typically connects to its services from his personal computer or mobile device. Anecdotal accounts—too many to be just isolated complaints—seem to indicate that Google isn't making enterprise search as much of a priority as its consumer search. Perhaps Google wishes to make the point that putting out high-quality services for end users alone is sufficient to keep them coming back and sustain its core business. Or perhaps Google views a major enterprise push as described above as repudiating its essence—going from innovating constantly in a creative work environment (but being somewhat of a lone wolf about partnering with others) to entering high-maintenance relationships with other large enterprises. Most importantly though, it comes down to a question of control. An expanded suite of enterprise services means Google would have to run its software in environments that are not fully under its control. Google's software would have to play reasonably well with other enterprise systems and there will inevitably be problems, including security holes, even with Google software. Google would have to be very careful getting into the business of off-site software installation and support—perhaps the hundreds of former Microsoft employees now in its ranks can be some help there.

If Google continues to dominate search in the consumer segment and provides a compelling and integrated value proposition to enterprises at the same time, large enterprises would be amenable to signing support and consulting contracts around enterprise search that could prove quite lucrative for Google. Fixing the flaws in its current enterprise search offering and recognizing the money other strategies can bring in would enable Google to diversify its revenue streams and continue rolling out free services, whose only ostensible purpose seems to be to increase the 'stickiness' of Google's Web properties. While some might argue that this would go against Google's essential line of business so far, enterprise search may well prove to be its only reliable revenue stream except online advertising, because the need for organizing the world's enterprise information is immune to the vagaries of business cycles, click fraud allegations and increased competition that plague Google's core business.

Posted by Vishy at 11:42 AM | Comments (0)

July 05, 2006

Vishy's Indian English Dictionary: flyover

flyover. /FLAI·ovuh/. Not the opposite of this other word. Not an epithet for the states of the United States that lack a coastline either. A flyover is what passes as an overpass (whoops) in U.S. English. Flyovers have been mushrooming in Mumbai and other major cities of India as a solution to traffic congestion that occasionally approaches legendary levels. In their wake they've been creating several opportunities for real estate development, both inside and outside apartments. I'd much rather live under a flyover than an overpass—it sounds liberating, airy and open unlike its infelicitous U.S. counterpart, a happy Jewish festival in reverse. Having said that, I am equally glad about the existence of overpass—imagine what New York's lovely DUMBF would be called otherwise!

Posted by Vishy at 09:15 PM | Comments (0)

July 04, 2006

Vishy's Indian English Dictionary: co-brother

co-brother. /KOH·bru·thuhr/. How two men are related if they are married to sisters. There is no corresponding kinsip term in Anglo-American English, which prefers to cop out with the term brother-in-law, as best as I can tell. To see why brother-in-law doesn't quite work, consider this (admittedly wildly unlikely) scenario: if Patty Bouvier, Marge Simpson's sister in The Simpsons had a husband, then Homer Simpson and he would be co-brothers according to Indian English. Homer would be Patty's brother-in-law by blood because he is married to her sister by blood. However, in American English, Homer would be brother-in-law to both Patty and her husband, by blood to one and by marriage to another. A separate co-brother kinship term frees up brother-in-law to connote a by-blood sense alone. A co-brother is the by-marriage equivalent of a brother-in-law. Co-brothers are occasionally called co-sons-in-law, because together they are sons-in-law of the same set of in-laws. And in case you're wondering, de facto Indian English usage includes a female equivalent to co-brother: co-sister, used to refer to the relationship between two women who have married brothers.

Posted by Vishy at 09:35 AM | Comments (0)

July 02, 2006

HSBC's Personal Internet Banking not!

HSBC, the self-styled 'world's local bank' advertises an online-only savings account that lets them offer a higher than average interest rate in exchange for lower overhead per retail banking customer. The online-only application process is more arduous than most, requiring multiple forms of identification and a three day period to verify the existing bank account from which you wish to fund the online savings account. Miffed yet patient, I jumped through the hoops, watching the high-interest carrot dangle before my eyes (that mixing of metaphors was intentional) and hoping that this treatment would improve once I actually became their customer. Being part of both the wired generation and Generation Debt, I have seen my share of Web services that purport to help me manage my money online. I've rarely encountered an online-only financial service as bad as HSBC's Personal Internet Banking. I continue to be their customer for now because of their inflation-beating interest rate but if the quality of their Web site was the only consideration, then I'd have stopped being their customer before even applying to be one.

HSBC's Personal Internet Banking service is not personal. After your application has been approved, HSBC sends you your online login credentials, customer ID and password, through separate pieces of snail mail. I waited eagerly for mine to arrive, only to find that my customer ID was--wait for this--a 20 digit number. I remember all of my frequently used credit card numbers, each 15 or 16 digits long, but only because I find myself giving them out frequently over the phone or online. This number is longer than all my credit card numbers, a fact made worse only by the fact that I would use it solely for this one Web service. The password is another 8 digit number, which means as much to me as my customer ID--nothing. When picking security keys and so on, the service requires the customer to click keys on an on-screen keyboard, ostensibly to thwart any keylogging spyware installed on the client computer. I imagine this mouse intensive task would be annoying to not-so-dexterous older users as well as keyboard-preferring younger users. I realize the need to protect against authentication and transaction fraud, but this is ridiculous. Far from being personal, these devices make the online banking customer uncomfortable. The message that HSBC sends to the online banking customer is 'This Web service is ours, not yours, and we'll make you jump through all these hoops to manage your own money!'

Despite showing an astonishing level of awareness about modern devices to commit online financial fraud, HSBC's Personal Internet Banking service is not an Internet service by my definition. The service offers only the thinnest layer of online transaction support, falling back on phone based customer service and antiquated snail mail devices at just about any pretext. Take the authentication credentials for instance. I have no opportunity to choose a personally memorable username and password. I am entirely dependent upon those two or three pieces of snail mail that contain the indecipherable and meaningless 28 digits I need to access my account. A online service that ties me thus to two insecure and easily lost pieces of paper is not an Internet service. HSBC's service also does not support instant online verification of my non-HSBC accounts, unlike some other services I have seen. Adding this feature is a simple matter of technical tie-ups with online banking services from other banks, something I have seen one of my other online banking services do already. Having non-HSBC online accounts verified via trial deposits should be a fall-back option and not the default. Forcing its users to wait three days for any non-HSBC account verification, especially if it is the same one they initially verified to fund the account, is hardly what an Internet service, with its implied instant-gratification tag, should do.

Consistent with HSBC's this-is-our-service-not-yours message, its web site also does nothing to protect the customer from phishing, which is becoming an increasingly effective vehicle for fraudsters to launch online bait-and-switch attacks. There appears to be no way for HSBC's site to identify itself to its users. Bank of America's site, on the other hand, lets users choose a personalized picture, called a SiteKey, which is shown to them before they enter their password. It's not foolproof, but it is certainly more than what HSBC does. All the above complaints are exacerbated by the fact that online-only customers have no recourse to a brick-and-mortar HSBC branch for any complaints. Even a minor site usage error means spending 15 minutes on the phone with a customer service representative, who asks you for your account number, which is another 9-digit number distinct from the other numbers mentioned above. One would imagine that the world's local bank, with its intricate knowledge of local customs, would come into the global Internet age, for once and wise up to its competitors' vastly superior online banking offerings.

Come on HSBC -- get with the program!

Posted by Vishy at 10:38 AM | Comments (0)