How managers choose programming languages

Question

It's not a secret to anyone that managers can and often will impose the programming language that will be used for a project.

Being a programmer myself, I have never been able to understand this.

But now I think I do: I've just had a revelation when Joel Spolsky said on the podcast that they should use QuickBooks because 'every accountant in the world knows it'. This struck me as being very similar to 'chose Java because every programmer in the world knows it'.

Now that I've seen the same issue from another perspective (I don't know much about accounting, but I do know something about programming), I'm wondering how can a programmer help make sure the right programming language is chosen for a project.

Answer 1

Become the manager. (grin)

Seriously, you just need to discuss the matter with the decision maker in question, and put forward your arguments. If they choose to stick with a really wrong decision, then their general competence probably isn't so hot and it might be worth looking for something else to do.

Answer 2

I think the difference between what you're talking about and what Joel was talking about is that programming is a core competency while accounting is not. The point using Quickbooks is, presumably, because you are not an accountant and accountants can help you with it. However, if programming is your core competency, and presumably it is if you are a programmer, then the rules of the game are a bit different.

Answer 3

Every platform has good and bad sides. .NET is cool and powerful but you pretty much stuck with Windows servers. Ruby is cool but slow. It would be hard to find developers for Haskell.

The point is, language affect not how fast project will be done and how beautiful code will be but also those stuff managers care about. So if you want to influence them, you should now they preferences and find as much good sides in their perspective as you possibly can.

Answer 4

These are different concepts.

When accounting, you share your results: for taxes, law, investors etc. They need a tool to see the result of you labor, and this tool has to be well-know.

When programming, you use any tool you want — as long as it outputs an .exe file that you can run on Windows. This is the exactly the same as a Quick Books readable document in case of accounting.

So, if you develop a toaster, you a free to keep your internal documentation in Chinese but you'd better provide an English manual.

There is one more thing: if you company's rules assume that the result of your code is not a product itself, but a source code for it, then for sure they may decide what it will look like (by chosing the language they want).

What they choose depends on their goals: if they want easily replaceable programmers they choose Java; if they send it to another department it will be that department's requirement etc.

Answer 5

From what I've seem in my company: When managers choose a programming language, they usually do so very conservatively - taking into regard what kind of programming skills are currently available in the team (and if it would be easy to hire additional ones easily), whether it is a well established language, trying to choose something that will fit the current infrastructure and not cause large efforts to make it fit into what's already there. When programmers choose a programming language, things often tend to be a bit different - they often like to have a new challenge and would like to got with the latest hot trend and choose something where they can learn new things.

Ideally, it all comes down to discussing the pros and cons between the manager and the dev team and finding the solution that best fits the problem. This usually involves a lot of talking and convincing :-)

Answer 6

It very much depends on the personality of the manager:

There are those that go for buzzwords. Just find out which buzzwords they like and use it when you talk to him in conjuction with the language you want to use.

Others will only trust things they know themselves (like VB 6.0 for example). Make your language of choice easy to understand for them ('you know, its just like in good old VB' - even if you are talking about Haskell...)

But in reality, most managers are not as stupid as we geeks like to think, and they can be reasoned with. What is important here is that you understand their point of view: They usually don't care about specific technical details, they care about results. So don't tell them that .net or Java or Delphi or whatever has this megacool terrific feature. Tell them that (enter your language here) is a good choice because it feature A makes for shorter development times in a project like this, or that feature B makes for fewer bugs and therefore shortens the time needed for testing. Just make sure your argument is sound, don't lie to him.

In other words: treat him like an inteligent being (he probably is).

Answer 7

Think about the language you are being asked to use very very hard. Make sure that you know it's not a good language for the job, then ask the manager if you might make a suggestion as to another better language to use for the job. Supply any information you can that proves that the language wouldn't be good for the job and see what he says. It can't hurt. :)

Answer 8

Choosing programming language is often a business decision. Customers/Users don't care. Here is short quote (from http://www.ericsink.com/bos/Geeks_Rule.html):

Programming languages are chosen mainly for business reasons. I spend most of my time working with languages that I don't really like because the languages that I'd like to work with carry business disadvantages that outweigh their technical merits. That's the nature of the game. I can accept the situation (my choice) or find a new employer. Whining about how I can't use Java or Python or whatever at work just isn't an option.

Answer 9

The mistake many programmers make is they will argue the point (or simply agree or disagree with it) based solely on technical merit. With management--and the business as a whole--you have to argue the busines case and the merits for the business first and technical merits second.

This goes beyond programming language choice and pervades virtually every technical decision.

Let me give you an example: PCs. Joel argues (correctly) that developers should have top notch machines because developer time is expensive. In this he's completely right. But how do you argue this? Simple:

Example: I do a build of the code roughly 20 times a day. Each time it takes 3 minutes. If I had a fast PC I could build it in 1.5 minutes. So for an extra $1,000 every two years I can get an extra half hour a day, which for a programmer earning $100k (with on-costs of another 50% at least), that equates to roughly $10,000 per annum of time.

But arguing at the other end is HR deciding one size fits all when it comes to policy and PCs so a call centre monkey earning $25k and a programmer earning four times that should for soem reason have the same PC.

Technology platform and languages will have lots of factors going into the decision mix:

• Strategic relationship with particular vendors. If your company is a Microsoft Gold Partner (or wahtever its called now) then good luck getting Java or Python in;
• The IT department arguing a particular config because the money for the PCs comes out of their budget;
• IT deciding everyone should run Windows 2000 because they don't people running Linux;
• What other systems the company already has (eg if they use Java for everything else it makes sense to use it for this even though on its own it might not be the best choice);
• Risk aversion to different platforms or languages simply from a lack of experience;
• More interested in arguing risk with upper management than making developers happy;
• Some managers make the decisions they do simply because their hands are tied;
• Budgetary reasons although this can work in your favour too as it keeps expensive boondoggles out of your house like PVCS, anything produced by Rational, etc;
• Legal department aversion to open source licenses;
• Not involving the technical staff in planning and project estimation;
• Familiarity on the manager's part with a particular platform (technical people are guilty of this too but in both cases its not necessarily a bad thing--with many tools that can do the job better the devil you know).
• Experience of the technical staff. If they're all from a C# background, why would they use Java, Python or Ruby? and
• many other reasons.

Whatever the case you need to understand the reason (and I guarantee you there'll be several reasons) and argue merits in those terms. Some programmers are quite naive in this department and seem to think such decisions are made out of ignorance or even vindictivieness when nearly always many factors are in play.

Answer 10

By separating concerns. Business should be in charge of business decisions and tech in charge of tech decisions. I like the term "Accepted responsibility". If I'm to accept responsibility I also demand I get to make the choices that concerns my domain of the problem. Business gives me and my tech colleagues the business demands and we answer with one or two alternatives of how we can accept the responsibility to deliver. It should never be like "we'll do it in Python or C#". Rather;

"We can accept two different responsibilities here: If we go this way, we can deliver this fast and we meet these business demands really well and these are a bit harder. We also could do it this way and that gives these business demands the trump. Alternative A calls for these these resources and alternative B means we need to also do this and this..."

Then business chooses, but note that business chooses based on impact on business things, not technical things. And they don't get to choose among alternatives where tech isn't ready to accept the responsibility of the tech part.

Answer 11

In my experience it's always depended on:

1. Do we have the resources to use the language?
2. Do we have the resources to maintain the language?
3. If we do not have the resources to use and maintain the language how difficult/costly is it to get those resources?
4. What is the "future" of the language (Is it going to be around and in use for a while?)

Unless the project needs something that only a specific language/platform/technology/framework provides it comes down to what we already know and use. Both hiring new people and training existing programmers is pretty costly for most companies. When hiring we always consider the language and make sure candidates know what language(s) they will probably be using.

Hopefully you have a programmer who is also a manager and who can represent programmers in these types of decisions. If not then that is a dangerous situation and you should talk with your manager if you know such a decision is being made.

Answer 12

Manager A goes to a summer retreat where he meets manager B.

A: So what language do you use in your company? B: Oh we use CA Visual Objects, it makes the drones so much more productive than COBOL.

And this is how the decision was made. End of true story.

Answer 13

Late reply, but since no answer has been accepted yet, I'll give it a try. I take it as two questions and will attempt to answer each:

How do managers choose programming languages?

Heavily depends on organisation size and manager experience, but generally will involve assessing current situation and future scenarios and requirements. This is usually done through PESTLE or similar analysis, just to give a few samples in each category:

• Political
  • "No one got fired for buying IBM"
  • CEO heard that Java is cool
  • Chief Architect loves .NET
  • The language is controlled by our competitors.
• Economical
  • Costs (licensing, equipment, AppServers etc)
  • Cost of training developers
• Social
  • Skill availability in house (training needs, continuity)
  • Skill availability on the market
  • Training, treats to existing status quo within the dev team
  • Availability of community of practise that is sufficiently large
• Technological
  • Technology capabilities
  • Backward compatibility with existing systems
  • Migration
  • Adherence to standards
  • Interoperability
  • Maturity
• Legal
  • Licensing terms
  • Technology control (Who owns and controls the technology? What is their future licensing strategy is likely to be?)
  • Legal and regulatory compliance
• Environmental
  • Existing infrastructure within company
  • Existing skills within company
  • Integration with external partners
  • Level of technology support by wider environment

Then a bunch of languages matching the criteria may be further evaluated using SWOT, cost benefit analysis or similar.

The whole process can be rather complex, but as a bottom line most companies or project teams will go for the safest option given their current circumstances that can still deliver the capabilities they need. Usually, this is the language they're already using.

How can a programmer help make sure the right programming language is chosen for a project

As it has been, hopefully, demonstrated a typical programmer would normally have just 1/6th of the total input into the decision making process. And as a rule she or he would mostly be interested in the language capabilities alone!

Well, the best way to influence the decision seems to have a broader picture of the selection process, make allies within and outside the team, make a good brief on technological side of things and try not to concentrate on the language capabilities alone.

And, of course, one needs to get into the position where a Project or Development Manager (or whoever else is in charge) sees the benefits of going through the entire evaluation process and is prepared to consider the risks and uncertainties of switching to a different language in the first place. For this to happen it needs to be demonstrated that:

1. Current platform is no longer inadequate.
2. A new platform promises benefits that by far outweigh the hassle.

However, would you had asked "What is the best way to be able to use at work the language I like", the answer would have been "join a company that already uses the language or start your own".