From: Chad Perrin Date: 2006-09-04T19:54:53+09:00 Subject: Re: Joel Spolsky on languages for web programming On Mon, Sep 04, 2006 at 12:37:03PM +0900, Vidar Hokstad wrote: > > Joseph wrote: > > Although I respect Joel very much, I believe he makes a fundamental > > mistake in his reasoning. > > > > Basically what he is saying can be deconstructed this way: > > > > * Do not risk developing in new cutting edge technology. Even if > > successful proof of concepts are already out there (37 signals et. al) > > * Use what most people use: PHP / J2EE / .Net not what most experts > > tell you to use. Communities and support are paramount. > > * Corporations and the people in those organizations favor safety, if > > your job is on the line go with the tried and true. Take no risks. > > > > All three assumptions rely on a single assumption: FEAR. > > No. They rely on sound risk management principles. One might say that's just euphemistic phrasing. I'm not prepared to make such an assertion at this time (I'd like to think about this a bit more before doing so), but it does occur to me as a possibility. > > > * Fear the technology would eventually not deliver. > > Replace "Fear" with "Risk" and the above is reasonable if your company > does not have people experienced in a particular technology. And fact > is today it is still far harder to find people skilled at Ruby than > many other languages. More importantly, there is too little experience > with many Ruby technologies for a company with no Ruby experience to > _know_ whether Ruby will be appropriate for a specific project. This brings us to the "real" problem: Decision makers need to know something about the technologies to be able to make the "right" decisions. One cannot effectively expect that any particular decision is more or less likely to be a good one unless the decision maker actually knows the options at hand. In other words, Joel Spolsky's advice about choosing "proven" technologies is nonsense: the real advice should be "Choose from among technologies you know. If you are not an expert at all the options that sound good, learn enough to be able to make an informed decision. Failing to do so does not guarantee that you will make the wrong decision, but it does guarantee that you will make your decision for the wrong reasons. Period." In other words, every time a nontechnical manager is given the responsibility of choosing a programming language and/or framework for a project, someone has screwed up. How can (s)he possibly evaluate the available technologies, or even the advice (s)he receives about them (whether from employees, friends, consultants, or Joel On Software) to be sure it's not a load of hooey without knowing the technologies personally? > > > * Fear the support will not be sufficient. > > Replace "Fear" with "Risk" again. The company I work for, Edgeio, uses > PHP for our frontend code (but Ruby for our backend) because when we > started building it I had concerns about the availability of people > skilled with Ruby in general or Rails in particular. Sure, Java and PHP programmers are a dime a dozen -- as long as you're willing to settle for a dime-a-dozen quality programmer. If you want programmers that are worth their paychecks, however, you significantly narrow the field no matter what the language you're using. Considering the learning ability and proclivities of excellent programmers, however, I rather suspect that you'll find as many excellent programmers who know "exciting new languages" as "boring old languages", Considering the direction language design has been going lately, "exciting new languages" are generally easier to learn, too. This means that if you choose to hire for excellence over familiarity with a given language, you're just as likely to find yourself constrained to choose an excellent C programmer over a poor Java programmer as you are to choose an excellent C programmer over a poor Ruby programmer -- but if you're working with Ruby, your excellent C programmer will probably pick up the language faster. I guess what I'm saying is that you're probably better off choosing excellent programmers and the language that works best, technically speaking, for your project. Choosing a language for which programmers are a dime a dozen regardless of technical merit is more likely to leave you with crappy software development, lightning-fast employee turnover, or (more likely) both. > > When we started hiring those concerns were validated: It's proved > extremely hard to find people with Ruby experience. While it's > certainly getting easier rapidly, not everyone can afford to take the > risk. In our case I decided to start phasing Ruby in for small self > contained components in our backend, and gradually take it from there > as we get enough Ruby skills through training or hiring, which has > proven to work well and meant that in the event that we'd run into > unforeseen problems, the effort involved in switching back to another > language would have been limited. Define "experience". If by "experience" you mean "has spent ten years developing enterprise applications in the language", darn right it would be more difficult to find people with Ruby "experience" than many other languages. If, on the other hand, you mean "has demonstrated aptitude, Ruby skill, and programming wizardry likely to prove to be an unequivocal asset to your team", you're probably looking in the wrong places (since you're unlikely to find that in college internship programs, where all they teach anyone is Java and .NET). > > > * Fear regarding your job safety as a corporate developer or manager > > who chooses Ruby or Ruby on Rails for some mission critical project. > > Which is very valid if you make a choice detrimental to the company, > regardless which language it involves. As much as I love working with > Ruby, if someone working for me picked it for something inappropriate, > and the project tanked badly, they certainly would have to take the > responsibility for the language choice. If you don't have Ruby skills, > or your team doesn't have sufficient Ruby skills, or there aren't > enough skilled Ruby developers available in your location, picking it > for a high risk project will certainly not speak to your favor with any > risk The problem is where people fear for job security based on choosing a non-conservative technology, rather than for choosing an inappropriate technology. Many people would never (under current conditions) choose Ruby over Java, even if guaranteed that the project would be completed with 110% requirements satisfaction within two months for Ruby or with a 10% chance of project failure, a 90% requirements satisfaction rate if "successful", and an eighteen month development time for Java -- all based on fear for job security. It's the "nobody ever got fired for choosing IBM" syndrome. Even if choosing the conservative technology is the Wrong Answer for the task at hand, it will be considered the Right Answer for job security by a great many people. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] "Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts." - Paul Graham