If the tech guy (or girl) advises going for a less common technology, and something goes wrong, he’ll get blamed. “Why didn’t you use Java/Oracle/IBM like everyone else does?”
And you can be sure that something WILL go wrong sooner or later… and this guy knows it.
He knows he has a mortgage, kids that have to go through college, a wife with a spending habit… why take any chances? What’s in it for him if it works out? And what if it doesn’t?
People avoid taking risks. Especially people who work a ‘safe’ job as an employee.
Is this the lizard brain at work?
For the record: There’s nothing wrong with Java/C# (or any other language for that matter). They all have their (dis)advantages on speed, memory usage, developer-friendliness, license/price…
Yet NONE of them fit all tasks and situations you can throw at them, while yes: you can use most of them to implement most tasks.
Do you have any idea how many programming languages exist?
Just look at this list. These languages weren’t developed because there’s hardly any difference between them, or because a ‘one size fits all’ language exists.
Now, if you are a developer/sysadmin, I probably needn’t explain. But as I’m hoping to enlighten the non-tech manager here, I think an analogy is in order.
Let’s say you’re building a house. Would you use nails or screws for all attaching situations?
No. Depending on the kind of materials you need to bond, the needed strength, the climate it’s in, the budget, how long it should last… you either use nails, screws, glue, cement, or god knows what else.
You use the right tool for the job. It’s the same with programming languages.
A project done in Java will cost 5 times as much, take twice as long, and be harder to maintain than a project done in a scripting language such as PHP or Perl. … But the programmers and managers using Java will feel good about themselves because they are using a tool that, in theory, has a lot of power for handling problems of tremendous complexity. Just like the suburbanite who drives his SUV to the 7-11 on a paved road but feels good because in theory he could climb a 45-degree dirt slope.
(I just used this quote to show that there can be some bias and strong opinions concerning certain languages. I also don’t like Java, but that’s beside the point.)
Yes, you can hammer a screw into wood (I tried this as a kid), but it will take a lot of effort and will provide less bonding than a nail. And you might hit your fingers in the process (I also did this as a kid).
Still not convinced? Do you know that some programming languages can be 100 times faster than others? And there are also other differences just as relevant as execution speed.
And though execution speed can be important, it shouldn’t be your guiding factor.
Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.
Yukihiro Matsumoto, Ruby programming language on Wikipedia
People sometimes dismiss Ruby because Ruby is slow. Well it is, and I don’t care. The biggest performance bottlenecks that I have day to day is the database, the file system, the internet and bugs. These are not problems with Ruby, so speeding it up will have a negligible effect.
Additionally, hardware is cheap and developers are not. If you can use a programming language like Ruby to make your programmers more productive, then you can increase the performance of your code with better hardware. You can buy the better hardware with the money you saved by making your developers more productive.
Graham Jenson, What is Ruby? It is fun and makes you happy!
I once was part of a team that had to make an internal web application. We didn’t have any Java experience, but the company already had some customer-facing Java web apps developed by the ‘webdev’ team. So we agreed to use Java.
After evaluating several Java frameworks, one of us bumped into this new thing called ‘Ruby on Rails’ (V0.11 at that time iirc). ‘Rails’, as it’s often called, was like a breath of fresh air after being bombarded with Java that seemed more like configuration than programming at that time.
There was only 1 problem: Rails uses Ruby instead of Java as its programming language.
Even so, we decided to go for it. We finished the project in considerably less time than the original estimate. This also helped management accept that we had neglected to use Java.
Was this all because Rails somehow made us work faster?
Not really, but it was very suited for this job, it was a really fun language (it still is), it was new and exciting, and because we were supposed to use Java, our asses were on the line in a major way.
It was the right tool for the job AND the right tool for us. By the way, last time I heard, this application was still running (I no longer work there).
And when we showed the hardcore Java aficionados, one comment really struck: “it’s easy that way.” And this wasn’t the last time I heard this (often concerning Ruby). And shouldn’t that exactly be the whole point? Making things easier?
Unfortunately, when technology is concerned, the decisions aren’t always that clear and we rely a lot on other (less?) relevant factors to guide us.
Why your devs might not like a language that makes their lives easier
When I started out as a pro programmer, the company I worked for made client software in a not-so-easy language/framework. Why? Primary reason: they wanted the software to be as fast as possible, which is very valid.
Unfortunately, the database technology we were using was so damn slow that any advantage the faster language offered was totally obliterated. This was a huge bottleneck. The language was like a Ferrari, but it was waiting 98% of the time for the database’s traffic light. And that light won’t switch to green faster just because there’s a Ferrari waiting.
(For the tech guys: we were using C++/MFC and an Access database through ODBC… ok, stop laughing, we eventually switched to faster database tech.)
It also took several minutes to compile the project, meaning that we couldn’t just make changes and test them right away. No, we had to wait several minutes to test things, or get an error (and in the old days, that could have been several hours, but only graybeards remember this).
When I suggested that another language/technology (Delphi) was really more suited for the job, colleagues argued: “there’s no demand for Delphi programmers, this isn’t good for us.”
They were right. For me, this was my first job and I wanted to make a good impression. However, they had already proven themselves, knew this wasn’t going to be their last job and didn’t want to lock themselves into a framework/language that wasn’t in demand.
And I have no idea if they would have been able to find Delphi programmers.
Besides that, we could be pretty sure that Microsoft (the manufacturer of the tool we used) would still be around in a couple of years… while Borland (the original developer of Delphi) always seemed to be hovering on the edge of bankruptcy.
Would we have been more productive using Delphi? I’m pretty sure we would have. It was just much more suited for what we were doing and more forgiving for the rather average developers we were.
Would it have been good for the company? Not if the devs ran away and couldn’t be replaced by others.
Would it have been good for me? In hindsight, no. Now I can put 8 years of ‘pro’ C++ development on my CV, which is a lot more impressive compared to Delphi/Pascal. A lot of people used Pascal in high school, so it’s often not taken seriously.
So how do you pick a suitable language/framework?
You should use what startups use!
That’s what I used to tell the CxO’s. And I was wrong, as most of them didn’t work for startups.
Tech startups are the hotbed of technology. They use cutting-edge tools and make amazing software that scales to millions of users. And you will have to look hard to find startups using Java/C#.
Why?
Technology is at the core of their business, and their goal is to grow fast or fail fast – which probably isn’t yours. You are probably looking for stability, and aren’t interested in failing, no matter how slow or fast it goes.
You’re part of a startup? You should have brighter guys on board than me who will tell you what language/framework to use. And pssst: don’t waste your time reading this, you’ve got a startup to grow!
So, should you just stick with classic, proven tech then?
Hell no!
The language and framework you use can make a real difference. I think that except for certain edge cases, the human impact far outweighs the technological impact.
Have your programmers experiment with alternatives. Even if they don’t get all excited and suggest ditching your current tools, they might just find them useful somewhere. Also, it will help to fight boreout and keep things interesting.
Depending on the kind of software you make, it might be worth investigating domain specific languages (DSL).
This is something that could motivate the seniors and benefit everyone.
I have worked in EDI in the past, and DSL’s would be perfect there. Of course, I’d do it in Ruby, but I’m biased.
But isn’t it hard to learn a new language?
The basic logical building blocks of all languages are more or less the same. To compare programmers to writers again: a good programmer can tell a solid, logical story, no matter what language or framework (s)he uses.
Regular learning will also make it easier to learn new things in the future. I like to think of this as keeping your ‘learning muscle’ in shape.
And it will certainly not hinder career opportunities to experiment with other tools.
Au contraire mon frère.
Finally, it will also help you attract new talent. A business that uses Java, but with some Ruby, PHP and Node.js where it makes sense, sounds a lot sexier to the kind of people you want (well, it does to me).
Some have even suggested using technology as a hiring filter.
“The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.”
Paul Graham, Great Hackers
But don’t take my word (or Paul’s) for all this. Your mileage will vary. There are too many different situations to provide a ready-made answer. I hope I still gave you some food for thought and provided some insights though.
If there’s any meager advice I could give it would be this:
- Talk to your developers
- Are they using the right tools for the job?
- Encourage experimentation. Without experimentation we’d still be using assembler (or gasp: Cobol!).
- Have them investigate DSL’s.
- Remember that this isn’t purely a tech/HR matter.
And know that something will always go wrong, and it often isn’t the technologies’ fault.
Had a good read? Sign up at here to get notified of future (dis)informative articles by email.
Agree? disagree? Let me know your thoughts in the comments.
Header image by Duncan Hull, used under CC BY 2.0.
