CHAPTER 9 ■ SCALING YOUR TEAM
273
something potentially more productive. For example, when Twitter started using Scala,
they created the Graceless Failures blog (
http://www.gracelessfailures.com/). This serves
as a way to share Scala experiences, good and bad, with the community.
No matter what the specifics of adding team members are, I strongly recommend that
Scala adoption be positioned to the whole team as a way to write code more successfully.
Acknowledge the problems of Scala’s youth, which include weaker tools, less documenta-
tion, and so on. But help your team members stay focused on what they can achieve with
Scala in spite of the challenges of learning a new language and using a new tools chain. As
they have small successes and the values of concise code, immutability, powerful type
systems, type inferencing, and so on show up as revised coding idioms, they will move
into a self-reinforcing cycle of learning more, getting better, and getting better results.
When they walk into a meeting and say, “I don’t know how I could ever go back to Java,”
then you know they’re hooked and that you’ve succeeded in bringing them on board.
Organizing Teams Around Scala
I’ve consulted for a lot of companies over the years. I often see a sad thing happen: the
very best coders become architects. It’s a pay raise and often a death sentence for those
who love to get their hands dirty with code. The architects get to attend meetings, write on
white boards, do a few UML diagrams, and do code reviews. While some architects like
this kind of work, others pine for the days of code slinging.
There is good news for those architects who like to code: Scala offers you a chance to
get your hands dirty, because you can express a lot of complex coding rules using Scala’s
type system. You can be the architect, go to meetings, and use Scala rather than UML to
express high-level concepts and complex relationships; and best of all, you don’t have to
worry about round trips because all the code is Scala. So, let’s see how different team
members fit into different parts of a project with Scala.
A senior developer with a good sense of the business domain and the coding conventions
may do well to design domain-specific languages for use by other team members. DSLs
deliver value because they allow the program to more closely match the language that
business people use to describe solutions in a given domain. As we’ve seen with Scala’s
parser combinator library as well as Specs, Scala makes it easy to create code that corre-
sponds to the language a human would use to describe the answer to a problem. Putting
senior developers on projects to design DSLs allows them to model the language of solutions
beyond OOP’s “is a” and “has a” to relations and actions that object can take on each other.
Junior developers and folks more comfortable with scripting languages (Ruby, Python,
Groovy) are well suited to be library consumers. They can assemble applications out of
the DSLs created by the senior developers based on the rules and structures defined by
the architects. These developers should have a coding experience that is not dissimilar
from that of writing Ruby or Python code. At the same time, the junior developers who
have grown up with Java have the comfort of Scala’s static type system.
19897ch09.fm Page 273 Thursday, April 23, 2009 4:33 PM