Be Clear

• Be clear what you want out of it. You should be asking what’s in it for you. If you’re going to use Scala, you should be able to explain why. Do you think being more concise will help you? Is it the benefits of functional programming? Immutability? How are you going to measure it? Will the whole team aim for a pure functional programming style like Haskell? Or OO? Decide which up front. Agree.

• Understand the team dynamic. Understand your team and what their wants and needs are. Gauge the team’s appetite and goals. Ultimately, everyone needs to buy into the idea and head in the same direction. If one or two people feel left out or pull in another direction, you’ll have problems further down the line.

• Set expectations. Talk to the team and management. Explain the risks and share your motivations and expectations. To set your expectations: learning full-on functional programming (think Haskell) is hard. Be prepared.

• Review. Once you’ve started, keep reviewing where you are. Are you getting out of it what you thought you would? Can you prove or disprove any of the assumptions you started with? Is the business benefiting? If you can be more quantitative and use measurements, you can be more objective. And don’t be afraid to change your mind. Maybe you discover that it’s not the right choice for the team. You can always back out.

Get Guidance

• Hire an expert. This is my single biggest tip. If you have a real expert on the team, they can guide you through the syntax and features, and, more importantly, the adoption process. They can hold you back when you shouldn’t be racing and open the door to new techniques when you’re ready. It can be hard to find genuine experts but they can be worth their weight in gold.

• Be active in the community. Attend events, conferences, and meetups. Create a community. Learn from others and share your own experiences.

• Look at open source. But not too much. It’s good to see how others have done things—I’ve certainly been exposed to some of the more exotic syntax via open source—but bear in mind that what’s right for them may not be right for you. Take it with a pinch of salt. Use other people’s code to inspire learning but don’t copy it.

Have a Plan

• Make a plan. Don’t just start your next project in Scala; be deliberate and have a plan.

• Think about your goals. Write them down, then sketch out the steps that will take you closer to you them. For example, if a goal is to get up to speed fast, you may want to run some lunchtime knowledge-sharing sessions with your team.

• Decide where on the functional programming continuum you want to be. Do you want to jump in at the deep end or adopt functional idioms later? One tip to minimize the learning curve is to avoid using native Scala libraries to start with. They often lead you into functional style and, at the end of the day, it’s another API to learn. You can always stick with the Java libraries you know, at least to start with.

• Make a commitment. Commit to your goals; don’t do what I did and sideline Scala to the tests. Actively decide on Scala and make a personal commitment to see it happen.

If you follow these tips, you should be clear about your goals and expectations, have an idea of where you’ll get guidance from, and have planned out your next steps. You’ll be facing the prospect of working with a Scala codebase, probably converting Java code and working with new tools and libraries.

In the next chapters we’ll look at some practical tips on how to proceed, including converting Java code and managing your codebase.