This article over at Patrick Peak’s blog really pissed me off today, and I wasn’t even in a cranky mood. I thought I’d post my reply here since it’s longer than most of my posts anyway. 🙂 Here it is:

You’re kidding me, right? Dave and Jamis, you guys went too easy on Patrick. This was, obviously, a cloaked, underhanded put down of ruby/rails developers, or just non-Java developers in general. Passive-aggressive, anyone? I had to read the post and comments 5 times, just to make sure that I’m not blowing this out of proportion. Sometimes, I’m embarassed to say I’m a Java developer.

Do you mean to tell me that if you don’t have ANT and you’re not using Java that you can’t properly develop and deploy a webapp? Come on! Everyone, at least everyone who knows what they’re doing, keeps completely separate development and production environments. The requirements (configuration, hardware, security, etc.) for each type of environment are completely different no matter what platform you’re developing for, and it’s very difficult to not separate them. Most developers keep various other environments for testing and/or staging as well, and they use build tools, version control, and scripts to tie everything together.

Heck, it’s even the same for desktop apps. Do you know of anyone who’d ship a binary to customers with debug symbols in it and assertions turned on? Not anyone who’s software is worth paying for. Build tools, development environments, and deployment strategies are not some bright new ideas dreamed up by the Java community. They’re common, everyday tools that all (well, most) professional developers have been using for longer than Java has been around. To assume that you have to be a Java developer using ANT to understand these concepts is not only naive, it’s plain conceited.

Basically, it all comes down to whether or not you know how to properly manage your project, your sorce code, and your deployments. The process is portable to any language and any platform. “Write once, run anywhere.” 😉

Update: As usual, I can’t say it as well as Dave. He always says what’s in my head so much better than I can. I guess that’s why he writes books and I don’t!

Every once in a while, I run across a fabulous article that Joel (Spolsky of Joel on Software fame) wrote a while back that I’ve yet to read. This is one of those articles. In this article, Joel reminds us that, sometimes, the complexity beneath our abstractions leaks through and can cause us a world of hurt if we don’t understand those complex things going on underneath.

This has bitten me in the past with Hibernate. Hibernate abstracts the database away from us Java developers. It’s a wonderful tool, and it handles a ton of complexity under the covers, but that level of abstraction can come at a high price when you spend 2 weeks debugging what should be a simple problem. Unfortunately, if you don’t understand all of the things that Hibernate is trying to abstract away, you end up doing stupid things that you never would’ve done had you been using JDBC, for example.

Someone once said, “With great power comes great responsibility.” As software developers, we have a responsibility to at least understand the complexities that our powerful abstractions hide from us, or we are doomed to a life of debugging problems that never should’ve existed. For our first lesson, here’s a link to another Joel article that reminds us that string handling is very hard under the covers (it’s crazy that I can call C programming ‘under the covers’ these days). Aren’t you glad we have ruby, python, java, etc.?