Middleware Matters

We currently have a few openings for software developers here at IONA, so over the past few weeks some of my colleagues and I have interviewed a number of candidates. Unfortunately, a surprising percentage of the candidates have displayed one or more of the following undesirable characteristics:

• Knowing nothing about IONA. If you're going to visit us for an interview, it might not hurt to go to our website beforehand to get some clue about IONA and our products. When I ask you, "What made you decide to come talk to us today?" I expect you to tell me what intrigues you about IONA.
• Showing no passion. If you show no desire to work here, then you won't. You don't need to jump around like a cheerleader, but regardless of your personality, it's not hard for us to tell someone who's genuinely eager from someone who's either just looking for any ol' position or putting on an act. If I ask, "Emacs or vi?" I expect to see some fire in your eyes when you explain to me how emacs wins every time, hands down. ;-)
• Stretching the truth about capabilities. If you say you know Java or C++ or Perl, then I expect you to be able to answer simple Java or C++ or Perl questions. That doesn't seem like too much to ask. I don't expect your response to be, "Well, I haven't really touched that language in a year." When you list programming languages or SCM systems or databases or IDEs on your resumé or CV, I assume that you've used them in some meaningful capacity and at least know their basics, not that you once saw them mentioned in a book.

From our side, don't worry about us hammering you with stupidly hard questions or ridiculous puzzles that amount to little more than frat boy hazing. Most people who resort to such tactics IMO have some deep-seated need to show you how smart they are, so if we did that, I wouldn't blame you for not wanting to work with us. Our interviews are direct and relatively brief, as we can tell pretty quickly whether or not you'll be able to fit in and deliver. If you're interested, you can find some information about these positions on our main website.

Via Stefan, here is a pragmatic posting that cogently explains that the enterprise software picture isn't as black and white as folks who constantly engage in the "enterprise vs. enterprisey" battle wish it were. I especially like the "Enterprise-Class Software" and "Software That Runs The Enterprise" distinction that the posting makes. I'll refer to these as ECS and STRTE, respectively, throughout the rest of this posting.

There are applications where ECS is absolutely necessary, usually due to a mixture of important technical and business reasons. IONA's many customers in telecommunications, finance, and manufacturing, for example, often require such software. If these folks merely laugh you out of the room for calling them "enterprisey" and suggesting that they should just use STRTE for everything they need, then consider yourself lucky.

At the same time, there are many things that can be solved with STRTE. Such software is far more flexible and far less expensive than ECS. The former may not perform or scale anywhere near as well as the latter, but it doesn't need to. The referenced posting rightly refers to STRTE as "the glue that never sets."

One way to view these two classes of software is to relate them along Geoffrey Moore's Technology Adoption Life Cycle curve. Often, but not always, ECS lies toward the right side of the curve, in the land of conservative users. STRTE, OTOH, is often, but not always, found more to the left, where visionaries and early adopters hang out. The argument between the two camps is therefore a natural one, not so much about pure technology but more about approaches and beliefs, and in fact it's not unlike the age-old and never-ending political and social arguments between liberals and conservatives.

Dynamic languages have been around for quite awhile, but today they're often at the center of the ECS vs. STRTE debate, as ECS is almost always built with "traditional" enterprise-class languages such as Java, C++, and C, while STRTE is almost always powered by Ruby/JRuby, Python/Jython, PHP, Perl, JavaScript, or other dynamic languages. For example, in his informative Ruby Ape Diaries, Tim Bray specifically mentions the integration problem and wonders if Ruby might be the language that ends up bridging the different language communities behind ECS and STRTE. Meanwhile, Jon Udell wonders why some continue to try to make the argument about choosing one or the other when you can have both together. Indeed, with JVM-based dynamic languages like JavaScript, Jython, and JRuby and CLR-based dynamic languages like IronPython allowing close integration of these languages with Java and C# respectively, there really isn't a need to choose one approach over the other. Rather, as Jon correctly points out, these systems allow you to have the best of both worlds.

This is kinda geeky (apologies in advance!), but if you verbally try to read "ECS STRTE," it sorta sounds like "Easy Street." Perhaps that's a sure sign that the combination of STRTE and ECS could make a lot of enterprise systems easier and less expensive to develop and maintain. Let's end the annoying "ECS vs. STRTE" arguments and keep working to use the best of each together.

Mark loves to point to articles like this one as a way of "proving" that SOA is bad. I don't believe for a second that SOA is a panacea, but honestly, Mark, you could replace "SOA" in the title and text of that article and others like it with the name of pretty much any technology or approach -- yes, even REST! -- and it would read pretty much the same.

As Jim points out in a comment on Mark's blog, the article is really more about process than anything else. I would generalize that comment and say that the problems the article talks about are almost entirely rooted in non-technical issues.

In my latest Internet Computing column, I explore what it takes to write extensions to Ruby. Imaginatively, I entitled the column "Ruby Extensions" (pdf).

All in all, I've found that writing such extensions is not that difficult. Using the extension APIs to augment your C or C++ middleware with a Ruby interface could quickly increase your productivity. Given that glue code has to be flexible and can change frequently, writing the more fluid parts of your integration in Ruby rather than a compiled language can ease your development and maintenance costs. Extending Ruby with the underlying C++/C middleware means you get this without forcing any reworking of the performance-critical parts of the system. It gives you the best of both worlds and puts you on "easy street." :-)

Unfortunately, due to space issues, I didn't get to cover threading issues in the column. Ruby currently simulates threads in its interpreter, like Java's ancient "green threads," thus making it hard to integrate with the native threading approaches employed by C++/C code. It also obviously makes it impossible for Ruby to take advantage of the multithreading capabilities of today's hardware and operating systems. Since Ruby threads are so weak and more under-documented than even the language itself, Ruby libraries tend to completely ignore threads, making for an overall non-thread-friendly system. For this reason, employing Ruby on the server/receiving side in a multithreaded middleware dispatching system or framework is probably a bad idea, unless you can lock around the Ruby parts and don't mind the resulting performance and scalability issues. I've therefore been keeping my Ruby work on the client or sending side, where it can be largely in control and not subject to the threading whims of the underlying framework. I've heard that Ruby 2.0 is supposed to fix the lack of native multithreading support -- can anybody point to some firm details on that?

Joel Spolsky writes again about how Ruby performs poorly, but his posting reveals a fairly fundamental misunderstanding of both the language and its community, IMO. He seems to assume that Ruby proponents claim that the language is good for every computing problem, but of course nobody in their right mind would ever claim such a thing about any language. I had the opportunity to sit beside Matz, the creator of Ruby, at a speakers' dinner at JAOO a few years back, and I found him to be not only very pleasant, but also incredibly humble. He would never argue that Ruby can do it all.

As I wrote in my previous blog entry, extending Ruby is pretty straightforward. The examples Spolsky gives of Ruby being too slow could all be handled via extensions relatively easily. As the old adage goes, use the right tool for the job.

I was going to write more, but DHH nails it.

JAOO, the finest software development conference on the planet, is upon us. The main conference days are Monday through Wednesday of next week. Monday starts with Werner's keynote, which I'm really looking forward to, and then the conference branches out into a number of interesting topic areas, as the schedule shows. And as is always the case for JAOO, the list of speakers is a veritable "who's who" of well-known technology leaders. JAOO takes very good care of all attendees, and especially their speakers, which is why they're consistently able to attract a large number of top presenters.

At most conferences, I usually don't go to any sessions. The talks are usually uninteresting and are often delivered by first-time public speakers who are nervous and sometimes barely able to stumble through their presentations. Not so at JAOO! Because of the high quality of the speakers and their topics, at JAOO I attend as many sessions as I can, and often wish to be in 2 or 3 sessions at the same time. And of course, after a day full of formal sessions, there's nothing better than JAOO's legendary social events to help you unwind.

Hopefully I'll see you there!