This guest post was written by Maarten Koopmans for Signify Technology. Maarten has over 20 years of experience in IT in various roles, and a decade with Scala.
So you work in a team and you have decided to pick Scala for large parts - or maybe the whole project. You may have divided this into smaller projects and are building one or two of Scala’s biggest strengths
- Via the JVM it has access to a wealth of libraries
- Scala is multi-paradigm, allowing you to mix and match programming paradigms that best suit your problem.
I want to talk a bit about the second part today, especially if you’re with roughly 10 team members or more and on a long running project. And that is precisely because Scala supports so many paradigms.
What you’ll see is anything from a “java with less-boiler-plate” to a hardcore functional style used in projects. And, as corollary, also in the libraries used.
So, let’s look at what we have:
- A medium/large sized team.
- A language that supports a lot of paradigms.
- Competing libraries, often also using different paradigm or functionality-wise overlapping.
I guess you know the risk by now – after a year you’ll end up with a codebase with different styles in the code, overlapping dependencies (maybe also using different paradigms). A nightmare to maintain or add new features. An example of a really bad thing that can happen is that part of the codebase is purely functional (which most developers find harder to grok initially, or at least they have to go through a steep learning curve), has a bug and the “functional programming heroes” are absent. They need vacation too, right?
Of course, the reverse could also have happened – or the paradigm used by a particularly library is wrongly used by someone with less experience, leading to lengthy PR reviews and all sorts of delays.
So how do we ensure that you don’t end up in a place like this?
First of all, set a minimum on the complexity, and much as important, set a ceiling on the complexity of the paradigms used (because we all love to learn new things and apply them). It’s ok to re-evaluate these on a periodic basis, but make sure the whole team is on board, and that PR reviews are checking on whether code adheres to the choices made.
Second, every dependency should be measured against this set as well. So as soon as you find yourself adding a dependency – check whether it falls within your set of supported paradigms.
Third, make sure that preferably one dependency is used for a particular piece of functionality. For example, Akka HTTP and Twitter’s Finagle are both great. Pick one, preferably one that matches your “paradigm set” best, without compromising functionality.
Note that all of these are team activities, where the technical team lead must ensure the process is followed and implemented at all times (from initial choice to every piece of code that goes in). A natural question is if it’s OK to deviate from these rules, and the agreed paradigms, or even a library/dependency that is already in use, in a different, separate component.
The answer is NO! Because it decreases the number of people that can dive in, or take over in almost every case.
Does this sound like you’ll end up in a boring project after a year? Well, it shouldn’t. You can re-evaluate the paradigms, and the dependencies on a regular basis (but not too often, that defeats the purpose), at the cost of – hopefully- minor technical debt. It’s also a good way to keep up with new things – because if anything, things change. In Agile terms, if you have a good constant velocity and can keep it that way or improve the velocity while making a change, you’re good. You could even take a small hit in velocity if you’ll increase after the new choices you’ve made (and technical debt you’ve solved).I have seen the above issue in several projects when code had huge technical debt because of diverging code styles and dependencies – hitting the project when a bug had to be solved or a new feature was needed. I hope this article has made you aware of this risk!
Next time we’ll take a first look at (part of) a more in-depth technical, purely functional library like cats, Shapeless, or circe.
If you are interested in using Maarten's experience in your company or project, contact Signify Technology for more information. Also, if you would like to feature your own guest blog post, please email billie.graham@signifytechnology.com.