TwinTechs

It’s official. Rails is starting to look like a shiny new hammer* in my toolbox. Actually, it’s been that way for a while. An insane level of productivity, easy to understand persistence framework (unlike hibernate), baked-in REST, lots of community support, opinionated development guidelines, works on the JVM, etc. What’s not to like? It’s probably at the top of my list of considerations for any new web application. Of course, I know that part of my fondness is because I’ve gained a good level of familiarity and expertise with it.

Tools you’re familiar with tend to be the tools you use for most jobs. We (the development community) like to expound about having the right tool for the job and how some frameworks and languages are better suited to certain problems than others. This is true, of course, although not always practical. When you are unfamiliar with a certain tool then you have to weigh the costs of having to spend time learning about it in relation to a project timeline. You may also find that the new shiny thing you’ve learned to use doesn’t quite crack up to be what the salesman made it out to be. Another negative outcome is that you might end up wasting time learning something that produced no real benefit (other than learning what not to do or use [struts2 and JSF come to my mind]) and drops out of favor in the community; i.e. you just spent months wrestling with some framework and nobody wants to pay you to use it anymore and now you somehow feel dirty from the experience.

I realize I’m oversimplifying a bit. I just found myself wondering about what kind of strategy I take in selecting new things to learn or recommending new solutions. I think it boils down to direct analysis and a good deal of hearsay and gut feel.

* i.e. when you have a shiny new hammer, everything starts to look like a nail so you’ll use your hammer even when something is clearly not a nail. But hey, maybe pounding it will work anyways.