Delivering Business Value Through Polyglot Systems (part 4 / conclusion)
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.
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.