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
    Are you able to list the advantages Scala has over what they're currently using for their business and technological needs? If so, I suggest you start by editing your question to include these arguments. – idoby Aug 29 '13 at 12:01
  • in Beginning Scala book, there is a whole large chapter discussing this topic in brief. Do you expect answers to your question here to cover it completely? Consider taking a look at guidance in help center: "Your questions should be reasonably scoped. If you can imagine an entire book that answers your question, you’re asking too much." – gnat Aug 29 '13 at 12:04
  • 2
    Do other developers favour your decision as well? Note that it can become a nighmare when one developer introduces a technology where other's don't know about and should start maintaining it. – Uooo Aug 29 '13 at 12:51
  • 1
    just tell them "it's a better way to write Java". In most cases, management doesn't get the difference between source code and bytecode. – Javier Aug 29 '13 at 16:02
  • There is a whole website dedicated to this topic, please check out go.typesafe.com – lutzh May 6 '14 at 10:43

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.

  • They will also consider maintainability and extensibility for future change and requirements. Example: flash is actually a decent option for some web applications, but might be ruled out because it is a dead end for iPhones, even when short term plans do not include iPhone support. – ptyx Aug 29 '13 at 21:43

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.

  • 1
    I want to add the caveat that both of your suggestions could run the risk of pissing people off. Plus, doing things in your free time means giving the company your time for free and sending the signal that you can handle more work. One should be very careful and consider the reactions of people he or she works with. – idoby Aug 29 '13 at 12:10
  • 1
    Well yes that is why I put the 'depending on company-culture' in there, anyway nothing wrong to some piss people off if it will be better for the company in the long run – David DV Aug 29 '13 at 12:13
  • I just thought it was worth expanding on. Pissing off people for the greater good (or personal long-term good) might or might not be worth it, that's for each one of us to consider. – idoby Aug 29 '13 at 13:09

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.

  1. 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.
  2. 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.

  1. 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.
  2. 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).
  3. 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.
  4. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.