As a developer I like Scala and could tell the management about technical benefits of the language. But even if management understands that a superior technology has business impact, I fear that they don’t understand what I’d be talking about.
What arguments would you present to managers with technical backgrounds (computer scientists not programming for many years)?
5
Managers are not interested in technical details, they are interested in efficiency.
To sell a new technology to managers, you have to convince them that this technology allows to produce a better product in less time with less money.
But are you sure that this is the case?
Can you prove that project X will be cheaper to develop when it is done in Scala instead of the language you are currently using? And how much time and money will it cost to find and/or train programmers to be proficient enough with Scala to benefit from the transition?
Before you bring up the topic, make sure that you have a good answer to these questions, and that you have independent references to back them.
1
The management understands also that new technologies bring new costs, extra training or finding other developers that know these technologies to help you in the project or to support it when you are not longer working on it.
The best way is to work on a convincing prototype during those quiet moments and/or in your free time to showcase the advantages of this new technology.
Or use it in one of the smaller projects without telling :p (depending all on company-culture)
Anyways you should have been doing this already because how could you otherwise be convinced that this new technology will provide benefits.
3
I think there are a couple of key things to keep in mind with respect to making the case:
Don’t start by suggesting a wholesale transition to a new development language. Figure out a way to start small and demonstrate success before suggesting a broader change. Pick a project that you know that you can knock out of the park using Scala and can act to highlight Scala’s strengths. Management is more likely to agree to an initial pilot than a full transition.
Make sure that you have clear arguments around some of the objections that are likely to come up.
- With respect to Scala, you should expect push back related to finding skilled developers. While Scala continues to gain momentum, it is a challenging language for those unfamiliar with functional programming to get their head around. There isn’t a lot of strong talent out there and not all developers can successfully transition from other languages.
- You should also expect to hear about the investment in the existing code base. If you have a large code base in another language, interoperability and leveraging that previous work will be important. If that code base happens to be in Java, your job is a bit easier. If not, you will need to be able to explain how Scala and your existing infrastructure can coexist. Some organizations are open to having a polyglot environment, but others can be dogmatic about having one standard which will make it more difficult to introduce something new.
Finally, you need to be able to make the case that there is a clear benefit in terms of the team’s ability to deliver, at least for the subset of projects where Scala is applicable. If you can’t clearly articulate that benefit beyond your preference for it, you will have a hard time succeeding.
- Start with your team, not your managers. “Our whole team want to use this” is something any manager will pay attention to, even if they ultimately disagree. Do not, in contrast, attempt to use your managers to impose an unpopular choice on your team. Even if it works, your professional life will not be worth living.
- Write something useful in Scala on your own time (by which I don’t necessarily mean at home, out of office hours – I mean without compromising delivery of your set objectives). Show how Scala made it easier. Show how Scala makes it easier for others to extend your work. This will be particularly useful if your team needs convincing (see above).
- Do some research about the maintenance implications for the rest of your organisation. How will this affect testers, application support, release management, continuous integration and so on? You need to find real answers to this. If your workplace already supports the JVM (i.e. Java/Groovy), this will be much easier but there will still be an impact beyond your immediate team.
- Be prepared to accept no for an answer.
If you fail in the short term, go back to step 1 above. Try and get your regular dev colleagues interested in Scala. If enough of them get the itch, they may make the case for you.