Pensieri di un lunatico minore

Shooting fish in a red barrel

Mr. McGovern is, as always, a fount of amusing statements and half-true assumptions. Let’s discuss it, shall we?

No large analyst firm has spent any time researching Ruby uptake nor have any of their clients asked them to?

No clue, nor can we have an idea as to what clients have asked an analyst firm to do for them directly. Nor can we know if the firms have spent any time looking at it, but have yet to formulate their “idiot’s guide to emerging technology” reduction of it. Who knows, but more importantly, who cares? If they haven’t at least looked at it, they’re grossly negligent in actually thinking for their money, and instead are waiting for others to tell them what to think. This wouldn’t shock me at some firms, but it should be the exception, not the rule. Analysts are paid to know more than their customers, and to be ahead-of-the-curve, not to trail it by a decade.

No Indian outsourcing firm and their bloggers have even indirectly hinted at the fact that they are using it for large enterprise applications?

Perhaps—and I have no evidence on this, but let’s just play Devil’s advocate for a moment here—it is because Rails reduces the overhead on this sort of project to the point that you don’t need an entire factory full of Indian programmers, but instead a couple reasonably-talented programmers can accomplish the same thing. There’s a massive amount of assumptions built into this question that have to be sorted out before the question could be judged to be valuable, or even interesting.

Much of Java is the slog of overcoming the tax of writing in Java. All the extra code you have to write that is simply templated code that everyone writes. This is why the IDE’s are so “useful,” as they overcome the drudgery of much of this idiotic code. Take setters and getters for example. Only someone who counts by lines-of-code could love that idea.

Even though there are lots of Enterprise Architects who use Ruby outside of work, they never felt it was worth the time to talk about it in any meaningful way at work?

Or perhaps they never felt that the client/customer/employer was open-minded enough to step outside the herd and have an original thought accepted as valid? You don’t know how many organizations I’ve been inside who manage through “industry consensus.” It might reduce your risk of getting fired but it definitely reduces your opportunity for reward.

If you were to write a mission-critical enterprise application on a Java platform to support 5,000 concurrent users it would be 50X faster than anything the Ruby community could dream of? It would also outscale Ruby by factors?

It might be 50x faster, and it might be 50x slower. The speed of an application is more a result of the algorithmic and structural choices made, and less a result of the language used. I’ve seen C++ re-implementations of COBOL applications that are an order-of-magnitude slower because people made either dumb-assumptions, or didn’t realize how optimized certain behaviors were in COBOL that are much more manual in C++. Familiarity with the Sapir-Whorf hypothesis is helpful here in understanding why the language might even change the ability of a programmer to find optimal solutions.

Using independent tools from software vendors such as Fortify or Ounce Labs, that Java is more secure than Ruby out of the box?

I have no idea, as it depends on how you define security. Even though that’s my focus, and has been for a decade, I’ve yet to see a client make a decision based on security at the end of the day. It simply has to be “good enough,” in most cases. Having said that, in the enterprise world, most security flaws I run into aren’t necessarily the kind that are solved by sandboxing and other techniques, but are instead logic-flaws that cause untold damage because they implement the wrong business process, or don’t verify the validity of data being pushed into the system. None of that is caught by automatic tools.

Maybe we should simply trust all those large consulting firms who are doing Ruby but simply haven’t published any case studies on it? I wonder why they are publishing case studies on other technologies though?

Because herd mentality drives a large amount of the analyst world? Trust me, once a single major firm releases a “significant” paper, you’ll see all the others drop them like so much detritus.

Curious to know if Ruby has so much potential, how come Venture Capital firms haven’t attempted to monetize Ruby? Would they lose money if they attempted it?

If my experience throughout the 1990s in the dot-com bubble, and then in multiple security-startups since then has given me any insight, it is because they are, as a general rule, also herd-thinkers. I hardly think that the judgement of people who thought that Pets.com was a great idea is something I want to base my business decisions on.

Would they lose money? Probably. They generally do. Only a tiny fraction of investments ever pay off. People like to focus on the Google-ish investment profile, but that’s a distinct statistical outlier, not a typical case. The typical case is a few million in investment that goes nowhere.

I also think there is a psychological issue at stake here, which is that the rise of Ruby on Rails also mirrors the rise of the anti-VC movement that eshews outside funding for bootstrapping of a company, and starting small. This is something that is under-the-radar of a lot of firms, but a lot of the successful Web 2.0 companies are bootstrapped without VC money.

Can you point to a single Fortune 200 enterprise whose primary business isn’t technology and a single revenue-generating mission-critical system built using Ruby? If you can’t, could you at least speculate as to when you think this will happen?

The fact that I can’t point to it doesn’t mean that it doesn’t exist. That’s a logical fallicy. I know, for example, that a major international industrial company, that implemented their entire ERP system in Python. That doesn’t mean they “discuss it openly.” Anytime a company takes a different path, they often keep it to themselves because they consider it a market differentiator. I’m not saying they do exist, I’m just saying the lack of discussion is not indicative of anything useful, and that it is typical in the early-adopter phase for many people to keep their choices to themselves.

Can anyone name a single Fortune 200 enterprise whose primary business isn’t technology and a single publicly available case study on how they believe they should pay attention to the productivity of individual developers? For every one you find, I will find at least ten who have reduced individual developer productivity in pursuit of more important goals

Um, OK. I’m not even sure what this means, but we’ll leave it out there. Productivity is a multi-dimensional measure, and at the end-of-the-day, it’s a measure of ability to forward the business goals, whether your time be spent writing code or working to optimize the existing implementation of business processes. Any company that says that’s a bad idea, or has a goal of “reducing productivity” is likely on a spiral that won’t end well. Perhaps you meant something else?

Underlying all this is the mistaken assumption that simply because something isn’t widely believed, discussed, written about, published and stuffed into a simplistic quadrant that it has no value, or isn’t successful. Coverage of technology by mainstream analysis firms is usually an indicator of having missed the boat early on, and simply being in the late-adopter phase at the earliest.

That’s a great place for some people to be, but it’s not the place I find interesting.