24

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 a programmer can help make sure the right programming language is chosen for a project?

14 Answers14

29

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 business 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 worker earning $25k and a programmer earning four times that should for some 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 whatever it's 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 have 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 it's 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?
  • 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.

  • Very good and detailed answer! –  Apr 05 '09 at 18:19
  • 1
    "expensive boondoggles out of your house like PVCS, anything produced by Rational". Hah! Funny because it's true ;) – Rig Dec 02 '11 at 15:38
  • My company is Microsoft Gold partner, but we do use ANYTHING we reasonably need. You need to present your case and fight for it, but everything is possible for smart people – Budda Aug 26 '16 at 20:40
16

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 :-)

  • Why the down-votes? –  Jan 31 '09 at 16:01
  • 2
    I down-voted because you didn't actually answer my question. You just said a bunch of generalities. Except for the last sentence, which can be seen as an answer. But it's pretty much useless. –  Feb 01 '09 at 00:01
15

Late reply, but since there is no accepted answer yet, I'll give it a try. I take it as two questions and will attempt to answer them separately:

How do managers choose programming languages?

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

  • Political
    • "No one got fired for buying IBM" - safe choice.
    • CEO heard that Java is cool - hype.
    • Chief Architect loves .NET - pet project.
    • The language is controlled by a hostile competitor - why Google isn't relying on C#.
  • Economical
    • Licensing costs.
    • Cost of developer training.
    • Code base migration costs.
  • Social
    • Buy-in from the team.
    • Skill availability in house (training needs, continuity).
    • Skill availability on the market.
    • Threat to the existing status quo within the dev team.
    • Availability of sufficiently large community of practice.
  • Technological
    • Productivity improvement.
    • Quality improvement.
    • Ability to interoperate with existing code base.
    • Adherence to standards.
    • Maturity.
  • Legal
    • Licensing terms.
    • Technology control (Who owns and controls the technology? What is 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. Quite often it might mean sticking to the current platform for longer.

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, create 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 when 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 adequate.
  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 probably been "join a company that already uses the language or start your own".

Vlad Gudim
  • 1,215
  • 2
  • 13
  • 16
5

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.

Spikolynn
  • 179
  • 6
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.

  • 1
    You raise some interesting points, but you are wrong about finding Haskell developers. Most people who program in Haskell don't do do so at a job, but they want to (and they are generally pretty smart) –  Jan 31 '09 at 13:19
  • 1
    I know they smart :) But that means they won't do support job because it's boring or you'd have to pay them a lot. It's like COBOL really, you could find a person who knows it but you'd have to spend a lot of time looking and pay more then you would for any other guy. –  Jan 31 '09 at 16:02
  • No you wouldn't I know well over 300 Haskell developers who would work the same jobs they do now for considerably less pay than they are getting now just to work in Haskell. – Rayne Feb 01 '09 at 12:35
2

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.

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.

1

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.

  • 2
    Programming is, more often than not, not a core competency for managers. –  Jan 31 '09 at 16:02
  • Well, presumably, it is a core competency of the business or department in a way that is much different from the discussion of Quickbooks. –  Jan 31 '09 at 16:09
  • I can't follow. Are you comparing apples to oranges? –  Feb 01 '09 at 00:05
  • Why the downvote? I just pointed out your flawed logic. As far as apples and oranges, I think pot meet kettle. What Joel was talking about wrt Quickbooks is much different than managers just choosing Java. –  Feb 01 '09 at 11:27
1

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).

Treb
  • 1,638
  • 15
  • 15
1

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. :)

Rayne
  • 999
  • 7
  • 10
1

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.

Peter Štibraný
  • 111
  • 3
  • I agree here. But I also think it's important to note that given the two roles Business and Tech, Tech will have the most important input on what language/framework will meet the business demands. The suits very seldom has the tech knowledge needed. –  Jan 31 '09 at 11:57
1

First of all, programming is another form of art. A very logical form of art. If your manager is keen on his extraordinary software projects, that are to some extend, works of masterpiece, then ask that keen manager the following:

How much energy and time would it cost Rembrandt extra to not paint with his favourite brush, but a brush that, after careful consideration of the management team, is handed to him, 400 years ago and prior to his works becoming famous. Will his painting be more or less worth you think?

Similarly, If you are telling a programmer what language should be used, then be consistent and also tell a painter what brush sizes should be used! OR, alternatively, just leave this choice to the folks who need to work with it every single day and (like most masterpieces) night!

Sam
  • 171
  • 4
  • Creating art using pastels vs oil paints would be a better analogy. However, the pros and cons still lie on the business side - even though the artist may prefer oil paints, the project may require cheap materials/may require less preparation time/may require more longevity for this client/etc. That said, the artist should have input into this choice, but he or she must realize that the burden of persuasion and proof lies on his/her shoulders. –  Feb 26 '13 at 20:57
0

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.

Quassnoi
  • 101
  • Metaphorically speaking, the toaster equivalent of what I'm talking about is management requiring the internal documentation to be written in Spanish because there are more people who speak Spanish on Earth. –  Feb 01 '09 at 00:07
  • Exactly. If Spanish speaking toaster assemblers are more readily available on labor market, documentation of course should be in Spanish. –  Feb 01 '09 at 19:48
0

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.