Top five reasons why Scala might not be the right choice for your next project

Although proponents of Scala push for its usage in a vast array of situations, adopting a new programming language can just as easily be a path to failure as it can be a path to victory. In some cases, moving a development team to a new language can do more harm than good, and that's just a simple reality, regardless of the language to which development teams are thinking about switching. Sober second thought is always a good thing, so if your organization is entertaining a move towards Scala, here are a few things to think about before completely switching gears.

Are deadlines looming?

Adopting a new software development language like Scala requires a very different way of thinking about programming. There is going to be a three to six month learning period for developers to get a handle on using the language on more than a very basic level. This is time that might not be available on an existing project. Switching languages mid-stream isn't likely to be a smooth transition.

Are compilation delays unacceptable?

The one thing that both sides of the Scala debate agree on is that the compile times are often excessive. This can make practices like test driven development a nightmare. Breaking the application up into smaller services rather than building a monolith is one way to mitigate this problem. But regardless, the way the language is constructed is inevitably going to create complexity in the compilation process. If these compilation delays break the flow of development for programmers who need to be in the zone to work efficiently, productivity will be negatively impacted.

Is Scala programming a good fit for your organization?

Organizationally, you want to be in small, tight knit teams. That's going to make it a lot easier to keep everyone on the same page.

Jack Singleton, software developer at ThoughtWorks

Switching to Scala may entail restructuring at an organizational level. Larger firms that handle massive and complex systems are in an ideal place to leverage Scala for its ability to elegantly solve difficult business problems, as evidenced by Twitter's piecemeal migration from Ruby to a Scala and Java solution. However, larger companies that employ larger development teams are going to face bigger challenges when developing with Scala.

According to Jack Singleton, a senior software developer at ThoughtWorks, Scala works best when developers work in pods rather than as a large groups. "Organizationally, you want to be in small, tight knit teams. That's going to make it a lot easier to keep everyone on the same page. If you're trying to keep coding practices consistent over a 50 or even 20 person team, that's going to become very difficult." In some cases, making a major change to how developers collaborate might not fit in with the culture, causing disruption.

Is your development team on board?

Scala works best for developers who like to take a meta approach and really grasp the underpinnings of a language. They will enjoy the Scala challenge. Those who have a more production-oriented mind set and who want to build things quickly using standard methods will be less enthusiastic. There's a substantial mental investment required to learn more than the basics of Scala, and while it is possible to become very productive with the language, experienced developers who have spent years or decades learning all the ins and outs of their favorite language may not appreciate being made to feel like beginners.

The fact that Scala is itself still undergoing constant evolution makes it something of a moving target, which can also add to frustration. If the majority of developers on a team prefer to keep using familiar tools and perfecting their existing skills rather than learning new ones, Scala will present an obstacle to getting the job done.

Is there really something broken that needs fixing?

What does Martin Odersky, chairman and co-founder of Typesafe and the creator of the Scala language, say about his brainchild? Not surprisingly, he feels it has a lot to offer in high-performance computing environments as well as specialized enterprise applications. However, even Martin admits that porting existing applications that already work comes with a price—and not every business should be prepared to pay it, especially if they' don't necessarily need it. Porting existing applications to Scala just for the sake of porting applications to Scala doesn't make any sense at all.

"Even if Scala is better in the standard J2EE setting, and I think it is to some extent, the effort to completely rewrite applications and methods is too great. If you have a known and solved problem, you will continue to use the same technology." In other words, if it isn't broken—don't fix it.

Organizations shouldn't switch just because there's an itch to try something new. The implementation of Scala should be a carefully considered business decision. There are many benefits to adopting Scala as an organizations language of choice, and the languages lack of verbosity and ability to scale linearly is well documented. Given the right problem, the right mind set and the right set of programmers, Scala can be used to bear an overwhelming amount of fruit. But like anything else, if used unwisely and for the wrong application, choosing Scala can lead to an overwhelming feeling of regret.

Are you thinking about moving to Scala? What is the driving force behind moving? Let us know.