Tuesday, August 25, 2009

Delivering Business Value Through Polyglot Systems (part 4 / conclusion)

In my previous three posts, I described my experience with maintenance, refactoring, and installation on a large project that used both Java and Groovy. In this post, I will discuss the "support nightmare" raised by Bill Burke in his blog post "Polyglot programming is the worst idea I ever heard". As I illustrate below, adding moving parts of any kind can make support difficult. But this shouldn't scare us off from adding another language - most of us work with multiple languages like Javascript, CSS, SQL and XML already.

Mr. Burke describes the "support nightmare" as follows:
A support call comes in for your product or application. It's obviously a bug, but where is the problem? Is it your application code? Your JVM? Your Ruby VM? Your Java library? Your Ruby gem?
To paraphrase, adding a language will make it more difficult to track down bugs when support calls are made. Of course, with the decision to add any framework, runtime or library, we add complexity to our applications. In my experience, I think adding another language is no different. Even if I have an all Java stack, that doesn't make it right to add any Java library that I want to the application environment. Too many times, I have seen frameworks injected into applications to solve problems that could have been coded by hand in less than fifty lines of Java. In situations like this, the conceptual complexity of learning a new framework doesn't make sense. The critical aspect about the decision to add any toolset to an application is that it must be evaluated relative to its benefit.

In reality, we already deal with multiple runtimes when we resolve support calls. If a value doesn't display correctly in a typical Java web application, the problem could be in any number of places. It might be a problem with HTML, a JSP tag library, a JavaScript function, a JavaScript library, server side controllers, business logic embedded in a service, a library utilized by these services, messaging to other systems, the ORM library or the database itself. This is why feel strongly that the decision to add anything to a system must be evaluated relative to its benefit. The expertise we utilize when evaluating a library can and should be applied when adding a language as well.

This final point about the "support nightmare" provides a nice segue to some concluding thoughts about building polyglot systems. The fact is we already use multiple runtimes and multiple languages. Even simple two-tier desktop systems will typically use SQL (the language), a SQL database runtime and whatever language the application is being built in. The reasons we already do it are so obvious, we rarely debate them. I remember the excitement I had when I was able to embed SQL in my C code instead of using Btrieve, an indexed record manager. Sure, the SQL based RDMS was more complex to install, hid more details under the covers, required a preprocessor for the C code and involved effort to setup and maintain. But the benefits easily out-weighed the effort for the applications I was building. In the same way, adding another language like Groovy or Python may require some effort, but the benefits in terms of a smaller, more expressible code base that directly reflects the problem domain can easily be worth it for the long run. Ultimately, we deliver greater business value to our customers with systems that are easier to comprehend, support, enhance and maintain. I've found that using the right language for the right job can help deliver such systems.

No comments: