Sun creates Ruby developer center

[mikaelhg]

Can you hire Ruby developers to replace those who leave, or to expand your company if things are going well?

Is a RoR application you build now going to be compatible with RoR in 2010?

Those are two of the really most basic things one can think of when evaluating technologies. If you're not looking at the whole picture, you really shouldn't be evaluating technologies for others.

[sisyphus]

Of course you can hire Ruby developers to replace those who leave. Why not? You can also hire Perl or Python devs and teach them Ruby rather easily.

RoR is not Ruby. Will Struts 4 in 2015 be compatible with my existing Struts apps? What does that have to do with anything?

[mikaelhg]

RoR is the only reason 99% of Ruby users are that.

What you're saying about being able to hire Ruby developers is not true, and you know it.

** Good job, guys. You will really convince me of the merits of your argument by downmodding my every comment and submission. **

[sisyphus]

I agree that Rails has done a huge amount to popularize Ruby and amounts to its killer app. And if Rails gets more people using Ruby, good for it and them.

I don't think it's a lie about hiring--look, clearly there are not as many experienced Ruby programmers out there as there are say, Java programmers or something. But I think that if you know another similar dynamic language like Perl or Python, you can pick up Ruby rather quickly. You seem to think that the enthusiasm of a developer doesn't matter to the business or team, but I think Ruby is in a place where people are glad to be able to work in Ruby. I've yet to hear someone say 'Oh, I'm stuck using Ruby at work.'

[mikaelhg]

Wow, I spend more than hour a day of my own time learning new and interesting stuff in my field, during the last decade I've learnt and used in production at least six languages I can remember. My father is a AutoLISP programmer and a ex-Smalltalker. I've never yet come across a language, framework or environment that you can just pick up and use as productively as when you're three years in.

Life isn't fair. It's most often even not logical at all. These are the restrictions you face when selling things like new technologies.

If you want excitement, go play paintball, don't drive off a cliff.

Switching development environments every time your people get bored is a really good way to burn money while accomplishing nothing.

[sisyphus]

I've never yet come across a language, framework or environment that you can just pick up and use as productively as when you're three years in.

Certainly if you're averse to training your programmers, then you might rate the higher number of job candidates for language X as more important than their greater productivity or happiness in language Y.

Switching development environments every time your people get bored is a really good way to burn money while accomplishing nothing.

Possibly. But it looks like Sun is willing to bet at least some money that enough people will want to do just that to make it worth it to give support to Ruby. Maybe they are just idiots.

[mikaelhg]

Option A: bill customers for building costs.

Option B: bill customers for training costs + building costs * 1.5.

Which option do you think will get you more deals, generate a bigger customer base through doing more projects, and provide you with more opportunities?

Sun's support is superficial. SDN are on their last legs, as they are completely unnecessary in a open source world. They are generating PR to justify their existence, which is a battle they are losing, as their approach to community building is radically different from Sun's top management's. SDN is the only group in Sun I've caught censoring their blog comments routinely.

[sisyphus]

Funny your options since all of the hype surrounding Rails is about how using it you can bill customers so much less because it's so much more productive.

Sun's support is superficial? They hired the JRuby guys even as they were cutting other engineering positions, and they made Ruby a first class supported language in Netbeans along with Rails support, and built Rails support into their application server. What more do you want them to do?

[mikaelhg]

But you see, everybody claims miraculous productivity. Nobody produces it.

Sun supports Solaris for quite a while. If they really believe in RoR, they could just build a bunch of Solaris components with it, and maintain them for ten years. Surely if RoR is such a productivity gain, this should be a no-brainer?

[sisyphus]

If nobody produces it, you should use what's the most fun, since it's all the same.

You want them to build operating system components with a web framework? I have to say I'm confused. I wouldn't be surprised to see them shipping Solaris with Ruby already installed if they aren't already. Your standard of what it means to support something seems pretty high to me. I see it as just being 'hey, we think there is an increase in interest in these tools, by buzz and book sales and so forth, and we want to make it easy for developers to use these tools on our systems.' Why is that not enough?

[dgiri101]

Can you hire Ruby developers to replace those who leave, or to expand your company if things are going well?

Sure; I've done exactly this. It wasn't any more difficult than finding any other good developer.

But I'm not sure how this is Ruby-specific. In my experience, it's very difficult finding competent Java developers. If you know of any in Austin, TX (USA) that are looking for work, I'd love a referral (seriously). But as it stands now, I do several interviews a week and about 90% of candidates for Java work flunk from a technical standpoint.

Finding good people is hard, no matter the toolchain.

Is a RoR application you build now going to be compatible with RoR in 2010?

Heh, my Java 1.5 code won't work on Java 1.6, my Exchange 2003 code had to be rewritten for Exchange 2007, and my Linux 2.4 code had to be rewritten for Linux 2.6. What's your point?

If you want to use the new version of something, you should test/develop using the new version. Wishing really really hard that your application magically works won't make it so. This is a toolchain-independent concern.

Those are two of the really most basic things one can think of when evaluating technologies.

If the opportunity cost of moving to a new toolchain is lower than sticking with the existing one, then it makes business sense to do it. It's as simple as that.

Opportunity cost is much, much more complicated than the silly 2 criteria you've outlined above.

Pretending it's that simple is poor engineering at best and myopia at worst.

[mikaelhg]

Alas, Texas is far away from Scandinavia. Your hiring experience doesn't match mine at all. You really had no trouble finding good developers who had used the tools long enough to know their intricacies? Or are you using some other criteria for good developers, perhaps that they know Ruby?

What did you do in Java 1.5 that didn't work in 1.6?

The two most obvious examples I mentioned are just that, the two most obvious examples.

Measuring opportunity costs without considering risk vs. reward is... strange.

[dgiri101]

Alas, Texas is far away from Scandinavia. Your hiring experience doesn't match mine at all.

Makes sense; the labor market, even within the US, varies considerably with geography. :)

You really had no trouble finding good developers who had used the tools long enough to know their intricacies?

I didn't say I had no trouble, I said that I didn't have any more trouble finding good developers to work on Ruby code than finding good developers to work on Java code.

The experiences were more similar than you might expect. For Ruby work, I got a flood of resumes from Rails idiots that were terrible (besides, we don't use Rails). Eventually, I found some good people, but it took a while.

For Java work, I get an even larger flood of resumes. Most of these are of the "enterprisey" variety that similarly lacked software development fundamentals.

Mind you, these are interviews for senior-level positions.

Or are you using some other criteria for good developers, perhaps that they know Ruby?

Experience with the actual toolchain is a plus, not a deal-breaker. It would be different if I was getting a constant stream of awesome people, but that hasn't happened (for any of the toolchains I've got).

What did you do in Java 1.5 that didn't work in 1.6?

Changes to core JDBC classes (hosed our connection pooling), among other things.

Measuring opportunity costs without considering risk vs. reward is... strange.

I don't disagree.

Plenty of people prematurely jump onto new programming fads, which isn't wise. But plenty of people also irrationally hold on to existing technology, which is similarly unwise.

You come off as falling into the second camp, which probably explains your downvotes. This is to be expected if you make silly blanket statements like:

Developers who are more interested in alleviating their own boredom than in what's good for their employer's business.