Sep 21, 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’s 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.

About the Author

Object Partners profile.
Leave a Reply

Your email address will not be published.

Related Blog Posts
Android Development for iOS Developers
Android development has greatly improved since the early days. Maybe you tried it out when Android development was done in Eclipse, emulators were slow and buggy, and Java was the required language. Things have changed […]
Add a custom object to your Liquibase diff
Adding a custom object to your liquibase diff is a pretty simple two step process. Create an implementation of DatabaseObject Create an implementation of SnapshotGenerator In my case I wanted to add tracking of Stored […]
Keeping Secrets Out of Terraform State
There are many instances where you will want to create resources via Terraform with secrets that you just don’t want anyone to see. These could be IAM credentials, certificates, RDS DB credentials, etc. One problem […]
Validating Terraform Plans using Open Policy Agent
When developing infrastructure as code using terraform, it can be difficult to test and validate changes without executing the code against a real environment. The feedback loop between writing a line of code and understanding […]