Delivering Business Value Through Polyglot Systems (part 1)
My answer to Peter Ledbrooks’s blog post “Are polyglot systems a good idea?” is “Yes!”.
He wrote his post after reading “Polyglotism is the worst idea I ever heard“ by Bill Burke. I don’t know Bill Burke personally but the post has a troll-like feel. However, beyond the rhetoric there are concerns that I see raised over and over again. These concerns are nothing new. Almost three years ago, they were the inspiration for developing my presentation “Real World Groovy”. In that presentation, I raise concerns about introducing Groovy into a Java project and I address each concern by relating my own experience having worked with Java and Groovy on paid projects.
Burke describes four “nightmares” in his post. These nightmares are based on the assumption that introducing another programming language into a project
- …..is just a big excuse so the developer can learn and play with a new language, or for a language zealot/missionary to figure out a way to weasel in his pet language into a company. Plus, you’d probably end up being average or good at many languages but a master of none.
Personally, I never had trouble sleeping when using Groovy and Java on the same project. In this series of blog posts, I’ll examine these nightmares one at time.
The “Maintenance Nightmare” concerns staffing and training. He describes the hypothetical situation that after the polyglot programmer has left the team,
- …your group is a bunch of Java developers. For any bug that needs to be fixed, these developers need to be retrained in Ruby, a new Ruby developer needs to be hired, and/or a Ruby consultant/contractor needs to be brought it. Multiply this by each language you’ve introduced to your project.
Hypothetically, this group of Java developers won’t be able to read and update the code written in another language without training.
My experience is the exact opposite. The code written in Groovy was readable by the other developers on my team. No formal training was provided. The developers on my team were good, but they certainly weren’t language zealots. One had about 8 years of DB2 & Cobol with less than one year of Java experience. Another developer had 10+ years in VB and various SQL databases, as well as some Java. The subject matter experts were insurance actuaries with programming experience in PL-SQL and Foxpro. On our project, all of these people were able to write and maintain the Groovy code without formal training.
How is this possible? Groovy wasn’t added to the project because of some technical itch that needed scratching. The process of choosing an additional language involved taking a non-trivial piece of functionality and coding it in several languages, including Java. Each version was reviewed by those who would be developing and maintaining the new system. At that point in time, no one on the project had any experience with Groovy. If anything, there was prejudice against Groovy because of the uncertainty. Groovy was selected because it allowed us to easily express the algorithms and business logic in a way that reflected the business domain. The Groovy code was both concise and readable, with a very high signal-to-noise ratio.
Circling back to the maintenance concern, my experience has been that Groovy hasn’t made maintenance harder. In fact, it has made maintenance easier. Even with significant time passing between authoring and maintenance, the Groovy code has been easy to comprehend because it reflects the business domain. I try to write my Java code this way as well. However, Groovy doesn’t have a lot of ceremony around it, so it is accessible for developers with experience in other languages. My team did not struggle to decipher what was going on in a given piece of code because it was written in Groovy.
It is my experience that bugs can be resolved in minutes or hours that would have otherwise taken hours and days. The problems were solved quickly because those with domain expertise – my client’s developers and subject matter experts – could see at a glance what was wrong in the code. Note that none of this required them to be masters of Groovy. I have heard similar stories from others who had seen performance improvements rewriting C modules in Lisp or Smalltalk. The performance gains came because it was easier to implement logical efficiencies that just weren’t practical in C.
Based on what I’ve seen over the last 20+ years, technology issues are not what doom projects. I can’t tell you how many times I’ve heard developers say, “If the client could just decide what they want, I could build it. I just need to know what to build.” The hard part is getting systems to do what our client’s intend them to do. In order to bring a system into production, the team must be able to reason easily and quickly through the code to fix business logic errors.
In summary, the readability and expressiveness of languages like Groovy make maintenance of polyglot systems easier. There is less code to write and maintain and it is more readable. The benefit to less code isn’t in less effort typing at the keyboard. Rather, it is the ability to get one’s head around the various parts of the system. In addition, this enables a broader group of people with business expertise to be able to understand what the program is doing. All of this helps avoid creating a big ball of mud. Keeping the code easy to read and understand is the key to avoiding the “maintenance nightmare”.
In the next post, I’ll address the “Refactoring Nightmare”.