Steve Vinoski's Blog

Via Stefan Tilkov: Assaf Arkin talks about his upcoming book, Ruby in Practice. I don’t know anything about the book, but it sounds interesting.

Assaf talks about having a nice Ruby interface for WS, and also talks about wrapping Websphere MQ with Ruby. It reminded me of some work I was doing about a year and a half ago, when I still worked for IONA: developing a Ruby wrapper for Artix. I left there before it ever saw the light of day, so I doubt anyone will ever see it, but it was pretty cool. It was implemented using only customer-visible C++ APIs, and it afforded at least an order of magnitude reduction in the number of lines of code required to get anything done. It used WSDL4R to interpret a WSDL definition at runtime and dynamically generate accessor functions for the service, i.e., there was no up-front static code generation. You could point the client at the service, and if the service supported access to its WSDL (typically via a ?wsdl query string added to the service URI), the client could download the WSDL and dynamically generate everything required to access that service. I wrote about how to develop such Ruby extensions in my Sep/Oct 2006 IC column.

I remember presenting an example of the system in an internal sales engineering meeting where the original C++ and Java code required 70-80 lines of code while the equivalent Ruby code was only 7 lines. It wasn’t 7 lines of obfuscated expert-only Ruby, either; it was quite easy to read and understand. The SEs, most of whom worked only in Java and C++, kept looking at it and scratching their heads. They’d say, “Hey, you forgot to do this!” and I’d say, no, that happens right here. And they’d say something similar about another required action, and the answer was always the same: no, it’s in there. Basically, Ruby allowed me to hide a bunch of crufty, verbose, uninteresting but required boilerplate and focus only on service interactions. Waaay nicer than the equivalent Java and C++, for sure.

On a related note, just prior to that project, I did some work with Apache CXF to develop a server-side JavaScript and E4X JAX-WS capability. Since I no longer work in the middleware or WS worlds, I haven’t kept track of that code, so I don’t know if CXF still supports it or not. But either way, given the fact that JRuby now exists, there’s no reason that someone couldn’t take that work and redo it in JRuby. It would be pretty straightforward.

Via Tim Bray, a commencement address by Bruce Eckel. It’s worth reading the whole thing, but I found this part especially interesting:

An even more fascinating metric is this: 5% of programmers are 20x more productive than the other 95%. If this were a science, like it claims, we could figure out how to get everyone to the same level.

Let’s say that this follows the 80-20 rule. Roughly 80% of programmers don’t read books, don’t go to conferences, don’t continue learning, don’t do anything but what they covered in college. Maybe they’ve gotten a job in a big company where they can do the same thing over and over. The other 20% struggle with their profession: they read, try to learn things, listen to podcasts, go to user group meetings and sometimes a conference. 80% of this 20% are not very successful yet; they’re still beginning, still trying. The other 20% of this 20% — that’s about 5% of the whole who are 20x more productive.

The lesson here is that if you want to be a great developer, you’ve gotta put in the extra effort that Bruce talks about. There are no shortcuts. In my experience, I’ve seen that there are quite a few developers who rarely read things that pertain to their profession, never attend conferences or talks, and certainly never look into trying new approaches that are even the slightest bit different from what they already know. Well, unless they’re forced to, of course, via organizational changes or layoffs. I don’t understand why anyone would willingly choose a profession for which they’re unwilling to invest in continuous career-long learning.

I also like what he says here:

You need to pay attention to economics and business, both of which are far-from-exact sciences. Listen to books and lectures on tape while you commute. Understanding the underlying business issues may allow you to detect the fortunes of the company you’re working for and take action early. When I first started working I looked askance at people who paid attention to business issues — that was suit stuff, not real technology. But those people were the smart ones.

Another reason to pay attention to the business side is that it’s actually rare that the best technology wins. I used to struggle greatly with this, and over the years I’ve seen many developers do the same. Understanding how markets work and how technologies advance in the marketplace is important for every developer, so they can put their work in perspective and perhaps be a little less religious about it.

So, from these ideas, my two recommendations for 2008 are:

1. Learn a new programming language or new approach that takes you out of your comfort zone.
2. Study one or more technology-focused business books.

In both cases, you’ll be very glad you did.

Reg Braithwaite again:

Maybe—just maybe—the person advocating the non-mainstream tool isn’t the elitist. Maybe they are the egalitarian, the one who believes everyone can program if given the chance. What if the person saying “No, no, that doesn’t scale to a team of one hundred hum-drum monkeys” is the real elitist? Maybe the elitists are the ones who are convinced that other, lesser programmers cannot be trusted to program.

Precisely.

Speaking of Reg Braithwaite, in this post he touches on team size and productivity. There are so many gems there, I could comment on just about every sentence, but I think this is my favorite:

If we know that bug per line of code remains amazingly constant, why do we try to scale code out in verbosity rather than up in abstraction?

I’ve very often wondered the same thing.

When I’ve given talks about dynamic languages and productivity, I’ve sometimes brought up the “bugs per line of code” constant. With dynamic languages, I generally write far fewer lines to solve the problem than I would in Java or C++. While that alone doesn’t guarantee correctness, of course, in my experience it sure seems to lead to solutions that are completed faster and with fewer bugs. Yet in those presentations, I’ve always gotten pushback on that idea from someone in the audience, typically based on the “static typing will save you” argument, which I’ve never fully understood despite having written, read, and fixed tons and tons of statically-typed code over the course of my career. First, the notion that you’re generally likely to have more bugs if you have more lines of code just seems like common sense, since there are just more chances to be wrong. Second, static typing does nothing to help ensure that you’re applying suitable algorithms and are correctly solving the problem, yet that’s where the bugs tend to be.

But it goes beyond bug counts — sometimes it even comes down to getting a solution vs. not getting one at all. The fact that you can quickly visualize and produce a solution in Python or Ruby, for example, means you’re a lot more willing to actually sit down and crank out that solution in just a few days, rather than agree to take on a multi-month multi-person task to try to drive that nail with a Java or C++ hammer. Not to abuse another cliché, but I truly have been there and done that, believe me.

Postings like these often seem to attract comments of the form, “Well, dynamic languages are just too dangerous; we have several hundred programmers and we can’t watch everything that every one of them does.” I think that’s precisely Reg’s point! But this also gets to another related issue, which is that if you build teams that you can’t or won’t trust, you’re simply creating a self-fulfilling prophecy. You’re essentially expecting your teams to fail, so they will. In that type of environment, you’re just not going to be able to attract or keep anyone that you actually can trust. Furthermore, if you’re that type of manager or leader, not only is the likelihood that you’ll be able to scale your organization quite low, but you have nobody but yourself to blame for the eventual failures you’re sure to encounter. Issues related to dynamic languages and static typing are the least of your worries. Rather than tying your developers’ hands, it’s far better to devote continual effort to instilling common values and culture across the organization so that your teams can work toward common goals without requiring constant centralized oversight. Read Peter Senge’s The Fifth Discipline for great insight into this area.

For me, dynamic languages mean increased productivity. It’s as simple as that. It’s because the programming languages I use actually can do this, and because succinctness is power. And if you’ve never actually tried developing real software in such languages, that’s too bad, because that power — that productivity — really is quite amazing.