Questions to answer before proposing to use a new language?

Question

What are the technical questions I simply must have answers for before I approach someone about introducing a new language?

I'm looking for the list of technical questions that without a really good answer, I should not even waste anyone's time by proposing that we use language X.

PS: (def X clojure)

Answer 1

What will your new language offer that an existing language doesn't already?

We have languages that do just about everything in every way today. So before introducing a new language, make sure there isn't one already existing that does everything your new language does. And make sure you know exactly what features your new language will offer that aren't offered in the same combination or at all by other languages.

Unless of course you're just doing this for your own education - in which case forget this question and have at it!

Answer 2

How will this improve my productivity?

If this cannot be answered pack up and go home.

Answer 3

What's the point? / Why?

How will it make my job easier?

Answer 4

So much depends on what you're currently using, what you're switching to and why that it's difficult to answer. But these are always important:

• What can I do if I choose a new language that I could not do before?
• What could I do faster than I can currently with the new language?
• How will the rest of the team cope with the introduction of the new language?
• If I left, could someone else new to the language pick up where I left off without too many problems?

Answer 5

What is the business case?

It comes down to ROI (Return On Investment).

It is not only about an individual's productivity but:

• the whole team

• impact on product lifecycle

• maintainability

etc.

Answer 6

How easy is it to pick up? I find this is not that important.

Does it have IDE support? Pretty important, but you can work without it.

Is there a debugger available? I think this is the most important question I would ask. Once you have a working debugger, you can usually get anything done.

Answer 7

Productivity with a language is neither the only factor, nor a simple scalar in itself. Important questions include:

• How easy is it to learn the language, if it's not already familiar to people on the team?
• How easy is it to become expert at the language?
• Does the team have access to one or more language experts who have the bandwidth to do the necessary mentoring?
• Are good learning materials (books, blogs, tutorials) and support channels (fora, IRC, mailing lists) available?
• Does the language (or some framework in that language) allow a competent programmer to write the software faster than what you're using now?
• How maintainable is the language? How readable is the syntax to a competent programmer encountering someone else's code for the first time? (Think of APL and Perl.)
• Is the language somehow better applicable to your problem domain than what you're using now (e.g., functional languages for distributed computing)?
• How well does the language/platform meet business needs not related to development speed (e.g., performance, scalability)?
• What are the available tools like, and what do they cost? Is there a debugger available? An IDE? Refactoring and unit test support built into the IDE? Build management and deployment tools?

Answer 8

A crash course in politics for engineers...

Despite all the mission-statement baloney meant to sound noble and emphasize community support, the real purpose of every business is return on investment or, equivalently, maximizing shareholder value. If it's a government agency, it's kind of still the same question but the legal owners will have no direct influence and instead you will have proxy owners, such as higher agencies or powerful individual officials.

Decisions, however, are almost always made by agents, and so the principal-agent problem (also called the agency dilemma) appears; the agents (the management) will make a decision in their interest, and not necessarily according to the shareholder's interest as is theoretically required. In a government agency this is almost 100% of the consideration.

Sadly, this stirs in all the Dilbert and Parkinson's Law complexities.

The best you can conclude is that decisions will be justified on the basis of risk, cost, and benefit, but will tend to be made on the basis of what credit and blame is in store for the agent and understood by the agent, which is a narrow risk consideration of questionable value to the principal but at least an identifiable one.

So, we should now apply this to the language question. Your manager is likely to avoid threats, risks, scandals, and controversies. His application of the principals's concerns will be mainly through the constraints of budgets and expectations. Here are some examples that should be mostly self-explanatory.

If you want to use Java or PHP:

• Everyone is doing it this way
• This is the industry-standard approach for this type of problem
• This is the low-risk approach
• Similar systems have been done many times in Java/PHP

(That's the "no one ever got fired for buying IBM" argument.)

If you want to use Ruby:

• Ruby is in the Tiobe top-ten (not quite an industry standard, so this is the best you can do)
• PHP and Java are higher-cost technologies (he probably has a budget as an attempt to mitigate the principal-agent problem)
• PHP and Java are going to be out of fashion "soon" (maybe not, but phrased as a "risk of appearing to stupidly use old tech', and implying the lack of later credit and recognition)
• Ruby is an advanced language with powerful abstractions for cost-effective development (a weak argument for the agent, but offers the possibility of credit. The least effective of all the arguments.)

If you want to use Clojure:

• You better prototype the system on weekends and evenings and present it as a solved problem.
• Emphasize parallel Java / Clojure development ("if necessary the entire system can be written in Clojure Java")
• Make all the Java arguments and then say something about "the best of both worlds"

Answer 9

How will this language help me solve problems in such a way that (I|my team|my company) wind up looking more awesome.???

Answer 10

Q1: Can I hire people with these skills?

Q2: When I call our outsourcing partner account managers, and ask how much would a typical fixed-cost project cost, if done in the usual way, or done using language X, is the multiplier more than 1?

Q3: Does everyone else in my department also have a favorite language that does about the same job as my favorite language, and should their favorite languages be used as well? What are the practical consequences of this?

Answer 11

A good question to ask is what is the size of the community around the language/framework. For instance, ruby/rails has a significant community around it, which would make me more comfortable that I would not be "the first kid on the block" to have to deal with a particular problem.

Answer 12

Why limit yourself to one language? Figure out which problems are solved best by which language and offer up services. If the bandwidth between the services is too high, then migrate the problematic services together based on which language solves both best.