Should the choice of programming language be a team decision or a management one?

Question

I just had a discussion with an employee of mine about the department programming language standard. He felt that the choice of the programming language should reside with the project team. I feel that management should have the overall decision on what language is used. If two languages fit the project criteria should the team's desire be taken into account? I'd love to hear the everyone's experiences with this.

Answer 1

I think team morale is going to suffer pretty terribly if they say "We'd like to use this language." and management say "No, you have to use this language instead."

It really needs to be a joint decision and everyone needs to back up their reasoning.

Answer 2

Yes. Both groups should have input. Many different aspects need to be considered beyond preference as well, although that can be an important one. Job market (ability to hire new people to work), language support, tools, etc.

Answer 3

You have to take the team into account, they're the ones that will make it. If they won't /can't work with the language then it's going to make getting the project done really hard.

Obviously the management will have the last say, that's what management is for, but they have to take the team's preferences/suggestions into account. I think they'd have to have a really good reason to not choose the language the team suggests

Answer 4

If your programmers are better at, say, Java than C#, then it makes sense to use Java if either of them will work. As with any decision at that level, management might have reasons to choose one or the other. They should listen to the team, but the ultimate decision should be theirs.

Answer 5

I feel that developers should indeed have a say in the language chosen. Managers in general seem to have a habit of going with "buzzwords". (Good) Programmers will hopefully know the best language for the job, an opinion based on years of experience that management may lack.

Answer 6

Bear in mind that management gets to keep the code if/when the programming team move on, also they need to hire new coders to maintain it in the future. So, if the team want to choose erlang or haskell, then management has the responsibility to the company to say no. (sorry to pick on erlang and haskell devs, but there aren't that many of you about).

Generally, this is the issue - the team wants to use something that benefits them in some way, but the focus should be on future of the code, which belongs to the company and is paid for by the company (ie your wages). They need to ensure its supportable in the future.

They also would be paying for your training too, so its pretty much up to management.

The team can make suggestions, and try to influence the decision and I'm sure all but the worst companies would listen carefully to the team, but its management's decision in the end.

Answer 7

Of course the team's input it important. If you make a decision about major architectural piece of your application and the team feels that they didn't have part in it, then you are going to have moral issues. The decision eventually should be made by management (assuming management is technical in nature) and the lead architects and PMs.

But one thing to remember when choosing a language is that you will have a higher rate o success when the team is more familiar and happy with your choice. If you listen to what they have to say and then come to them with concrete business and technical reasons why you didn't go with their choice, then at least they felt lie they were heard and were a part of the process.

Answer 8

As with most things in life, an equilibrium must be reached between what's good/fun for the individuals (each of the team members) or for the organization (which should be the focus of the managers).

Answer 9

My experience in our workplace, management have a discussion with the technical team, where the technical team gave suggestions on the programming language that we are familiar and best work in. Then the management decides the programming language that the department uses. It should work both ways, since the technical team must be comfortable working with the programming language (to be able to deliver on schedule), and for the management, they can plan for medium to long term on the business, resource management and training.

Answer 10

The team - no question about it,

Answer 11

A good project manager will let his senior engineers make this decision and do his job: manage the project, i.e. shield the development team from "upper-level-management-BS". A good project manager will also require his senior engineers to justify in detail why they went with a particular programming language (if the choice of language is at all that important). If he is not satisfied with the justification I think it is his/her job to steer the development team into a direction that everybody can live and work with. Forcing a language on a development team? Not a good idea. The project will be doomed to failure.

Answer 12

In my opinion, it depends very much on the situation.

Of course you should take their desire into consideration, but one big thing to consider would be what language is the team going to most productive in. Also a big one which sometimes is over looked, is who will maintain the project in the long run and what are their competencies?

The last one for me is a pretty big one, too often a programmer goes off in some odd direction with some edge case technology mainly because he/she want to "try it out" or because it's new and hot. In those cases, maintainability is often largely forgotten and it comes back to bite the company, once that programmer is gone and someone else has to pick up the maintenance of the project.

On the other hand, if your team feel very strongly about it, is it worth causing a rift?

So again, at the end of the day, it depends on your situation and what type of project it is.

Answer 13

I think there are dangers with both approaches. Programmers might tend to go with the cool and fun up-coming technologies, and management might go with the heavily-marketed or commercialised technology (but unpopular with the anti-microsoft dev team ;) ).

There needs to be someone in an architect role that can liaise with both groups, and make an objective decision based on the business goals as well as developer concerns. This person needs to understand the overall goals of the system, weigh up infrastructure required by clients, robustness and support for the technology. etc...of course it does depend on the size of the company/project as to the impact of these decisions.

Answer 14

Agree with other posters that it should be a joint decision. But - often management has to take a longer term view than just the project team, for example the ongoing maintenance effort. So the lifetime of the software can be a factor. If the team chooses something which isn't mainstream, they are always going to have a fight on their hands.

Additionally, the final say usually belongs to the customer. If the project is in-house, then the customer may be just local management/tech. For other customers, the team will need some very pesuasive reasons to push back against their wishes.

Answer 15

The real question is what is the benefit of choosing one language over another:

• Functionality: What can get the job done better both now and in the future? Will this technology decision prove a rock-solid decision for the future of this project and do I even care about that (from a management position, of course)?

• Costs: Will I have to buy additional hardware or software for this technology choice? Do I want to be stuck with that hardware/software? Is the development staff versed in the technology being suggested or will I have to hire new blood?

• Time: How much time is it going to take to use this technology? Am I going to have to train people to use this?

The fact of the matter is that management should be asking these questions and development should be a sounding board for them.

Answer 16

I'm sorry - but in what other branch of engineering would this even be a question? Boeing's designers deciding that it would be cooler to use rocket engines instead of turbofans?

Answer 17

This is actually a "trust" question in disguise.

When management has trust, the choice is a no brainer (let the expert technical guys decide).

I'd suggest any team going through this situation to look at the underlying trust issue instead of focusing solely on the language issue.

Focus on the root cause and the result/symptom will work itself out.

Answer 18

Your first concern should be whether or not the language does the job. Mark Twain said: "To a man with a hammer, everything looks like a nail." So, just because the team is familiar with a language, doesn't mean that it's the best tool. On the other hand, developers that are well seasoned in a language and are domain experts would have more productivity working with their own tools.

The second concern is availability of developers. When the team moves on, who's left to support it? It can be costly to either hire or retrain for an obscure language. The language may also be new enough that the developer base may not materialize.

The third concern is availability/stability of the tool. Are you going to have to do constant rewrites every time the language changes (I'm thinking of VB/.Net). Also, who's supporting it? What happens to the language if the vendor gives up on it?

The short answer then is that if the team has a preference, they should present a strong argument for their choice; compelling enough to convince the boss that the salesman's kickbacks aren't worth the hassle. Try to understand management's reasoning so that you can accept the decision if you can't refute it.

Answer 19

The choice of languages for a project should include the teams preferences not overriding the correct choices for the project and it's environment.

The programming team should have more experience with the languages on the short list than the management team as that is what they were hired for and should be technically better qualified to judge what technologies will be better suited for them to work with.

Only if the management team is at least as well qualified and experienced in the choices should they attempt to influence the collaborative choices of the team unless there are non technical business implications to the choices, and these should be presented for consideration.

Good management let's it's employees do what they hired them to do and deligates where they can, so IMHO the choice should be delegated to the programming team.

A happy programming team will be more productive, end up with a better result, and wont grumble if they have difficulties working with their choice.

Management should be more concerned with the final project completing on time, within budget, and with a positive result then with what technologies are used unless the choices have a specific business impact that needs to addressed.

The programming team members and the management team members are all on the same team and everyones needs should be considered including what technologies the programming team members are most comfortable using and think are best for any each project, IMHO this should be a prime consideration only overridden by business needs or factual technical considerations.

Just to qualify a valid business reason to not support a programming teams choice might be that the technology was not mainstream enough to allow team member replacement at a reasonable cost from a reasonably sized pool or easy interface to current or planned resources.

Answer 20

Ultimately, it has to be management's choice only because they bear the burden of the aftermath if programmers leave, as well as representing the company's interests in the choice. A language selection must consider not only the current programming team's abilities/skill sets, but also all future members and any support staff in terms of marketable skills. You don't want to pick too obscure of a language if it means you can't find qualified people to support it. Additionally, if the language is nearing the end of it's popular/supported life, there is the risk that it becomes obsolete to the point that it needs to be rewritten sooner than it would be hoped.

I'm making the broad assumption that the maintainability, capability and type of type of the language choices are not fundamentally different (i.e. ML vs. C++).

All that said, if those factors are kept in mind, and the language choices are on equal footing otherwise, then using the language choice of the team would be best for morale and will lead to a better product without affecting the long term prospects of the application.

Answer 21

Consider the language. If its an easily fillable programming position (that is, if you can hire someone in a week's time to fill a job of one of those programmers - should they leave), then go with the team's recommendation. You wont believe how much work they'll do if you give them that bit of say. Otherwise, you may need to fill multiple positions. Dont bet on a bad economy keeping software developers in their seats. This is actually a perfect time to shop around. Keep em happy, but make sure the language choice is not some obscure, dead language.

Answer 22

I'd definitely consult with the team doing the development at the time. Give them the design document and get their feedback. That at least makes them feel like their decision counts.

Managers need to consider other things, like, cost of training staff in the chosen language, cost of purchasing IDE's (if required), cost of maintenace of the code base after initial development is completed.

After the manager has made an informed decision, the developers should feel their able to ask why the particular decision was made. Leave the decision to management but promote transparency of decision.

Answer 23

There's a lot to this question. In the end the person(s) paying for the work make the choices. But:

• Unless management is smarter about coding than the people they've hired they should consider their input. The management usally doesn't explain to coders that there are expenses associated with each language choice that may make other choices more desirable. This breeds resentment in coders when they feel their advice was ignored.

• There are a fair number of individuals who have seriously flawed judgment. They know only one language so they only recommend that one. Management may have already made up it's mind and will ignore it's employees good advice. Coders or management may be excessive technophiles and will embrace technical solutions even when they are not in the best interest of the project. They may also have strong opinions and have insufficient emotional maturity to allow others to disagree.

• Employees may also knowingly suggest things not in the best interest of the project owner because what they suggest is in their own best interests.

Mostly I believe the choices are made for emotional reasons not rational ones.

Answer 24

It is interesting that the choice of programming language should be such a significant issue for management, whereas depending on an elaborate open-source library or framework will often be done without much consideration.

Historically, there has been some logic in this, because changing programming language meant changing platforms, but now that programming languages are standardizing to run on the CLR or JVM platforms, sharing the libraries and deployment environments, the cost of diversifying to use different languages can be less than that of depending on complex frameworks.

Eg, if your application needs a rule engine, it might be better to use a JVM version of prolog, than to depend on some obscure Java rule engine API.