Aug 26, 2009

Delivering Business Value Through Polyglot Systems (part 3)

In my previous two posts, I described my experience with maintenance and refactoring on a large project that used both Java and Groovy. In this post, I will discuss the installation concerns raised by Bill Burke in his blog post “Polyglot programming is the worst idea I ever heard”.

In describing the “installation nightmare”, Burke states:

    But you still need to package and install all the appropriate Java libraries, Ruby gems, and Python libraries on the appropriate places of your user’s machine. You also need to hope that all the desparate environments don’t conflict with anything the user has already installed on his machine. And that’s just with languages running in the JVM.

These are valid concerns, but I don’t think they are exclusive to polyglot programming.

The problems of developing code that “works on my machine” but doesn’t work anywhere else are well documented. In my opinion, the first place to start with any project is a one-step build that provides for automated testing plus some form of continuous integration. This isn’t a particularly original idea these days. In our project, we used Ant to implement a one-step build using a clean checkout from version control. It took effort to get this working, but the effort involved would have been required whether Groovy was involved or not. In my experience, migrating from desktop Windows to Linux and then to AIX became a non-event once I had a one-step build in place.

In response to my previous blog posts on this topic, it has been pointed out that Groovy might be a special case. This is true to some degree in that Groovy was designed from the beginning for easy integration with Java. However, I think the concern about conflicts among libraries on different platforms is valid with or without Groovy. I’ve experienced first hand the unexpected differences in string truncation among IBM’s DB2 drivers running on different platforms. On Java projects, there is always a concern about a conflict with Antlr or ASM when using Hibernate and some other library that uses byte code generation. Adding Groovy is no different than adding any other library or framework to a project. There are always risks. Fortunately, one step builds and continuously integrating on all of your project platforms are tried and true strategies for mitigating this risk.

Finally, my thoughts with regards to non-JVM languages are different than those expressed by Mr. Burke:

    Imagine if you used vanilla Ruby, Python and Java all as separate silos!

I would encourage you to take your imagination out of the decision making process and base it instead on facts by testing things for yourself. For example, with Python, you might find that not only is it already installed on your test and production platforms, but your required libraries might be there as well. It also might be that installing the required libraries is trivial. Of course, it is possible that it is not trivial. The important point is to try it out and then evaluate the cost/benefit to your particular project. If the benefit is replacing 10,000 lines of the most complicated part of your project with 2,000 lines of code that is more readable and easier to “reason about”, then even the extra effort of engaging your infrastructure team to install a required Python library might be worth. Remember, the costs don’t exist in isolation but in relation to the benefit of adding another of language. The importance of this cannot be overstated.

At the end of the day, the business doesn’t exist for IT’s benefit and comfort. It is our job as developers to deliver systems that represent a good value to those making the investment. Where appropriate, we shouldn’t be afraid to utilize more than one language if it adds value to the project and take advantage of techniques like one-step builds and continuous integration to mitigate the risks.

In my next post, I’ll address the “support nightmare”.

About the Author

Object Partners profile.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Modern Development Environment for C++: Part 2
In Part 1 of this series, I gave a quick overview of each tool in the development environment and how I came to the conclusion that the tool was a good fit. Today I’m going […]
Mock Intl and Date globals in Jest
In Javascript land, mocking the browser global objects can be a bit of a pain for tests. Searching StackOverflow gives plenty of complicated answers. Some suggesting using 3rd party mock libraries. Some that overwrite the […]
Bitbucket Parameterized Pipelines
Introduction I’d like to address how to handle lots of deployment environments withinBitBucket Pipelines. Below I’m presenting two options: Using tags to parameterize builds Using the BitBucket API to pass variables Lots of Environments There […]
AWS Cloud HSM, Docker and NGINX
There is quite a bit of easily searchable content on the security benefits of leveraging a Hardware Security Module to manage cryptographic keys, so I will leave that to the scope of another article. The […]