How much freedom should a programmer have in choosing a language and framework?

Question

I started working at a company that is primarily C# oriented. We have a few people who like Java and JRuby, but a majority of programmers here like C#. I was hired because I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs.

I have recently started on a project building a web application with a focus on getting a lot of stuff done in a short amount of time. The software lead has dictated that I use mvc4 instead of rails. That might be OK, except I don't know mvc4, I don't know C# and I am the only one responsible for creating the web application server and front-end UI.

Wouldn't it make sense to use a framework that I already know extremely well (Rails) instead of using mvc4? The reasoning behind the decision was that the tech lead doesn't know Jruby/rails and there would be no way to reuse the code.

Counter arguments:

• He won't be contributing to the code and is, frankly, not needed on
  this project. So, it doesn't really matter if he knows JRuby/rails or not.

• We actually can reuse the code since we have a lot of java apps that JRuby can pull code from and vice-versa. In fact, he has dedicated some resources to convert a Java library to C#, instead of just running the Java library on the JRuby on Rails app. All because he doesn't like Java or JRuby

I have built many web applications, but using something unfamiliar is causing some spin-up and I am unable to build an awesome application in as short of a time as I'm used to. This would be fine; learning new technologies is important in this field. The problem is, for this project we need to get a lot done fast.

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

Answer 1

I'd say you have to talk to the team lead and say something like:

I know you guys are a .NET shop, but I was actually hired for my Java/JRubyRails skills. I can build this new application in X amount of time using those tools that I already know. I could learn C#/mvc4 like you want, but it will take >> X amount of time. What do you want?

This raises the issue of "skills-you-were-(assumedly)-hired-for" vs. "skills-you-need-now" and also shows that you're willing to learn the new skills, but that it will take longer to develop the new application as you are new to this tool-set. And you do want to show that you're willing to learn new skills. Not being open to learning new skills is a good way to ensure your employment ends when your skills are no longer needed.

As to your question at the end:

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

It usually depends on the company. If a company buys MS tools and standardizes everything on the VisualStudio platform and .NET framework, it could get very awkward if one developer insists on using Linux and C. That is normal. Exceptions might exist where the company is less fussy about the editors, such as letting developers choose Vi vs. Emacs, as long as the output is the same. I know some companies even let developers choose Windows vs. Linux, but the language they work in has very good support and runtimes for both OSs.

Why do companies do this? Consistency is one reason. It can be very difficult to debug things when the application is a patchwork of binaries built in the favourite languages/frameworks of various developers, built in different tools, and tested on very different systems. If all developers work on mostly similar set ups, those sorts of problems are resolved.

In your case, it sounds like you were hired to work in technology that is non-standard in this company. This seems strange to me, and you might want to talk to the person who hired you about why they wanted that.

Answer 2

At what point should a developer be allowed to choose his tools?

When they don't impact your team.

Am I looking at this the wrong way?

Absolutely.

Yes, you have a short deadline. Yes, you could get it done faster in Rails. But the company as a whole needs to deploy and maintain the application. If the company has a stable of good C# developers, then it will probably be cheaper (and yield better quality) to have a C# app to maintain.

Your DBAs and other admin staff are probably familiar with that stack and have processes in place to deploy and update that stack. Even if you can get the code done faster, it might take longer once you account for all of the overhead needed to get a professional web app up and running.

Remember, you're going to spend way more time maintaining your app than writing it. Optimize for that cost.

Answer 3

1. You were apparently hired because of your ability to adapt to "new" technologies. C# is no different, in that regard. Are you sure you don't want to take the opportunity to learn something new?

2. ASP.NET MVC is very similar to Ruby on Rails, in many ways.

3. You won't be at a snail's pace forever. If you already know ROR, ASP.NET MVC will be a cinch for you. The trick is learning C#.

Answer 4

Arguments for staying with Java/JRuby

Chances are, your boss wants you to produce. They hired you so that you could add value to the company. Ensure that they understand that by forcing you to use a framework that you aren't familiar with they will cause you to:

1. Produce results at a slower rate
2. Create lower quality code

Even the best programmers require warm up time with new languages/frameworks.

Arguments for Learning MVC4 and C#

Learning new languages is good. Investing in your skills as a programmer is only a risk if the language/platform you're learning is going to disappear in the near future, and with Microsoft chugging along, I don't think that that's an issue. C# and MVC both have had recent updates improving them both, with even more updates in the pipeline.

Making you, personally, a more well rounded developer will keep you from being put in this situation ever again. The best part? Your boss will be paying you to learn these things, meaning that you get paid to make yourself worth more money.

The Bottom Line

You may end up winning this fight, but you'll be left working with disgruntled colleagues. Just explain the pros and cons of each to your manager and then you'll both come out the other end happier.

Answer 5

At what point should a developer be allowed to choose his tools?

When said developer is the software lead.

Certainly, you can (and should) make the case for using the different toolkit if you're concerned about productivity, but be prepared for an answer you won't like. There may be a damned good reason why your lead wants you to use a specific toolkit, be it compatibility with the current architecture, concerns about maintenance, licensing issues, etc.

BTW, the phrase

with a focus on getting a lot of stuff done in a short amount of time

is responsible for more heartburn and mayhem in the software industry than just about anything else.

Answer 6

I note that you don't say you were hired as a JRuby or Java programmer.

Here is why you said you were hired: "[B]ecause I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs."

In other words, they like your web experience and your willingness to learn new technologies.

Now they're asking you to use your web experience and to learn a new technology.

So the question is, are you going to do that, or not?

Answer 7

The Biggest Expense in Software is in the Maintenance of it

I read that the biggest expense (80%) is in the maintenance of software. The initial development is only 20% of the total cost of development.

I read a case about a developer who developed code and comments in his native language (not English) and when the other team members went to enhance and maintain the code, it was next to impossible because the language (not any programming language) was foreign to them.

Similarly, if you develop code in a programming language of your own choice, it would be difficult for other team members to maintain.

Solution: Pair Programming

Consider asking your employers to pair you with somebody else that does know the required programming language and you can work together. You can learn from each other, and if either of you leave the company, the other one would know the code.

Wikipedia Article on "Pair Programming": http://en.wikipedia.org/wiki/Pair_programming

Answer 8

Many companies simply prefer to stick with what they've always done or what's "safe". There's a reason Java and PHP are still very popular. At the moment, searching for "COBOL" on indeed.com returns 2144 listings...that should really speak for itself. The industry doesn't care about good code, it cares about code it can milk for as long as possible (this doesn't imply C# is bad, it really isn't).

Think it about this: the code is going to outlast you. There's a good chance that someone else is going to maintain your code and C# is a safer bet than Node.js and Rails. It wouldn't surprise me if in 5 or 6 years the number of Ruby programmers halved, after all the same happened to Perl and any other language that has been considered at some point the "it" web language. Javascript isn't likely to go away but we're already starting to see it being used as a sort of ASM (or even C) of the web - an intermediate language other languages can compile to so writing server-side code in it could very well become obsolete.

Answer 9

My main concern with developers choosing how to implement their goals, is that they normally assume only they will be editting the code. Look at it this way, 12 months later they may need changes; you aren't available (left the company or really busy on another task), and another developer has to churn your code. If its a C# shop, then using their toolset is good teamwork. New technologies should be investigated and implemented, but only when the lead thinks the time is right, as they have their eye on many goals not just one.

Answer 10

Turn it around, please. Imagine you were the one hiring a Ruby developer, and they insist on implementing their work in Asp.net/MVC.

What would you say to them? This is our stack, man. Learn to live with it.

The golden rule, here is, she who has the gold makes the rules.

Answer 11

There are a number of conflicting goals and the problem is to find the best compromise. We have the deadline, we have an team lead that requests a certain toolset, and we have a developer inexperienced with that toolset but doomed to produce something within a (obviously short) timeframe.

It's important to understand, that the team lead has probably some good reasons why he demands exactly this toolset (one of which could be indeed to get you used to this toolset for some reason that you might not know yet). The best thing you can do at the first run is to find out, what these reasons exactly are.

Put into your position, I would try to talk to the team lead and try to explain the situation, as it is in your view, and the options and which outcome (incl. short-term and long-term economic effects) will be generated following each of these options. For example, another more experienced developer could be assigned to coach you, maybe with some pair programmng sessions or the like.

Unless your team lead is a complete moron, you should be able to find a consensus that makes sense with regard to the project and to the overall goals of the company.

Answer 12

Bah. Everybody is wrong.

Be a better dev than those one-platform people are and you'll have a lot more interesting options than they ever will. So, for now, DO learn MVC. And on your own time, learn more about the platforms that really interest you. Build your Node skills. Learn some Django. Pay attention to whatever Java or pre MVC .NET shenanigans you're exposed to and then run away but at least learn enough to be able to criticize and explain how much thought you've put into your barely concealed burning hate prejudice of those platforms. (okay, maybe I'm projecting there)

And now for the important advice. If you continue to hone your specialities while also diversifying your expertise in other areas, you'll eventually be in a place where you can find new work at any time of the year in less than two weeks in any given major city doing stuff that is mostly interesting at least half the time. When you find yourself in this place, don't put up with these jobs where they say they want this and by day two they have you doing THAT with no hope of a reprieve foreseeable in the long-term future. Just politely explain and apologize but no you really didn't want to do THAT and said as much at your interview and then !@#$ing quit and move on when a couple weeks roll by and they've inevitably done nothing to accommodate for the fact that they misrepresented the position to you and refuse to acknowledge that.

But trust me, finding a new gig is always way better than getting seriously irritated and unhappy for any amount of time lasting longer than 5 minutes. But of course, first you have to pay your dues so you can do that. Some people never will. That's why they want everything in the stuff that they know best. And of course other answers aren't really wrong. It does make sense for a .NET shop to go with .NET if they have to maintain the silly thing.

Of course, what doesn't make sense is why they'd diversify with a Rails/JS/UI dev and only have him do MVC apps. But for now. You may need to pick it up and pay your dues. And as I said in comments MVC's really not that bad. A really bad choice given all the options but certainly not the worst. It's pretty straightforward, doesn't throw 10,000 layers of abstraction on top of everything that's actually happening, and doesn't get itself so twisted with the client-side that you'd curse the names of the MS engineers responsible if anybody could be bothered to learn them.

So get to that place where you can leave when you want if you haven't already and you might even find you have a more skeptical eye of things you currently like. You might even find yourself disliking rails as much as I do. Not that there's anything wrong with Ruby (other than its interpreter of course).

Answer 13

Depending on your situation, it could be dangerous to assume you know why they hired you, and even more so to assume your manager knows that and agrees that hiring people with your skills is a good idea.

I would ask take the advice above and make a business case why you should go with JRuby over C#, maybe your argument and timelines means breaking from the old ways makes sense. I would not just assume it is okay or not, give the manager or lead the facts and let them make the decision, it is what they are being paid the big bucks for, plus its a bit of CYA.

Answer 14

In my honest opinion, one of the things that separates good developers from great is their ability to adapt to new technology. We are living in a fast-paced world where today's top technology will become obsolete tomorrow. Hence, a developer that is unwilling to adapt is of limited use to the company. This would be fine, if not for a little fact that finding and hiring good people is really really difficult to do and when a company finds their gem, they are planning for the long run.

I have seen companies hiring out of their technology scope and they do it for exact same reason. They want to get hands on great developers, even if that means waiting for them to adapt to new technology.

Now to your situation. As a new guy in the group, I would be very careful as to what I say and don't say to my superiors. Sure, you will get away with a lot based on the assumption that you are still in a process of adapting to your new environment. However, undermining authority and stubborn perseverance at your preferred technology will only make your superiors think they did a mistake hiring you and that you are not willing to leave your comfort zone.

What you will pick is up to you, but I would suggest you trying to learn new technology. It won't hurt, I promise.

Answer 15

I'm going to assume that you were honest up front during your interview about your lack of C# knowledge, because if you weren't then you might be in a very precarious position from a legal standpoint.

Good programmers know programming. Whilst nobody can obviously be well-versed on all languages and frameworks, there is considerable commonality amongst most of them. Unless you're being asked to work in a language that's massively different from what constitutes the mainstream these days (Lisp, for example), then a good programmer should be able to adapt.

Naturally there's a learning curve. If the employer hired you then they must be confident in your abilities to follow that curve in a reasonable amount of time (again, assuming you were honest up front regarding not knowing C#). The C# language borrows heavily from Java, and in more generally, most class-based programming languages are fundamentally quite similar (you mentioned node.js, which builds on top of ECMAScript, which is a prototype-based language, so you're obviously comfortable with other programming paradigms.

Good programmers should, in addition to being flexible, be eager to learn new things. In software development you're generally either learning or becoming irrelevant.

Of course your employer, assuming they knew you didn't know C#, has to meet you half-way. If you show eagerness to learn then they have to give you the time and resources to do so. Throwing you in at the deep end is unfair and needlessly stressful. You need to sit down and have a calm, rational discussion with your superior. If they want it in C# then they must be prepared to accept that you'll be on a learning curve whilst working on it and it would be unfair for them to impose tight deadlines on you. If the deadlines aren't flexible and if they are of high strategic importance, then they need to be prepared to allow you some latitude to get the job done within that deadline. If they need it to be in the more commonly-used language in their office, then you can perhaps request to implement it now in what you're familiar with to meet the deadline, and then as your next project re-implement it in C# as a learning exercise and to bring the software into compliance with internal requirements once it meets the external ones. Like I said, most of the more commonly-used languages today have a lot in common so it mostly come down to implementation details.

You do have to be prepared to accept sooner or later that you're working in a C# shop and therefore you do need to have C# under your belt.

Answer 16

Maybe they're not satisfied with the way everyone is using MVC in the .NET environment. There could be too much treating it like webforms. This is no different when someone with a procedural background starts out in OOP, put everything in one big class and goes on with business as usual.

This first project is not the ideal situation because they want this done so quickly. Get up to speed on .NET as much as possible and start cranking out features as fast as you can. You're not going to like the way you're doing things, just try to keep in mind you'll start to refactor this stuff and apply your skills in another language.

Hopefully, your way of using MVC4 (assuming everyone else there is not doing it quite right) in a more Ruby-Style will catch on and break everyone away from the Webforms mentality.