Wouldn’t life be easier if there were a yes-no black-white this-not-that answer to everything? Well, there’s not, not for questions and situations of any complexity. Is Ruby or other interpreted, dynamically-typed language appropriate for enterprise software development? Are functional specs useful? The answer to both those questions is not yes or no, it’s maybe. To answer either question and most questions of interest in software development, you have to look at the actual details of the situation at hand. Yeah, it’s harder to do that, just like it’s harder to make moral decisions if you have to think for yourself instead of referring to dogmatic assertions about right and wrong. But you’ll get better results.
James McGovern suggests that Ruby may be a train wreck waiting to happen, at least as regards its use in large companies. I like Coté’s reasoned response better than David Heinemeier Hansson’s snark, but both are worth reading to get a sense of the issues. James makes some worthwhile points on the way to his conclusion. My favorite is that “the productivity argument is lame.” Many new languages and technologies promise wild productivity gains; few can bring that to enterprise-level software development, because productivity on such projects is determined mainly by factors other than the technology in use. For example: how many developers are on the project, how do they communicate, how well do they know the language they’re using, what kind of relationships do they have with the software users? How complex are the algorithms involved, what are the performance requirements, what legacy software do they need to integrate with? In the short run at least, introducing a new language or technology will decrease productivity, not increase it, and in the long run, any productivity gains will likely be tempered if not entirely overwhelmed by other factors.
My main problem, however, with McGovern’s approach is its fundamentalism. His answer to the question “is Ruby enterprise-ready?” is “absolutely not, and here’s why.” The more interesting answer would be “no, but…” or “maybe, if…” Then we could talk about what situations might benefit from a language like Ruby (or Python or PHP or whatever scripting language rings your brain’s bell) and how it might make inroads into enterprise development. Or how it already is. That’s what I’d like to know: how are large companies using popular Web development languages like Ruby and PHP? How do they get introduced? What technological and sociocultural factors influence uptake? How does their use get disseminated through vendor and IT organizations?
David Heinemeier Hansson’s critique of McGovern is more reactive than reasoned and while it’s not an ad hominem attack, it seems unnecessarily disparaging towards the practice of enterprise architecture. But HH’s response is not so shocking when you consider that he’s part of 37Signals, the firm that brings us the idea that you shouldn’t write a functional specification document and that functional specs subvert the hierarchy of nature. Here’s my response to that idea. 37Signals has its own Bible and they evangelize their way with stunning effectiveness. I haven’t studied their Bible or prayed over it, but my sense is that their principles may work great for some Web 2.0 startups aiming at individuals and small to medium-sized businesses and not so well for situations of greater complexity. Still, I bet any developer could benefit from reading their ideas and seeing how they might be modified to fit her own project’s needs. You don’t need to take them as gospel to get value from them.
I’m not sure that I want to call for an end to black-and-white positions like those staked out by McGovern and by the 37Signals crew—that would be a fundamentalist position itself, wouldn’t it? We learn by taking strong positions and setting them up against each other. We can create a dialectic, where opposing positions are put forth again and again in response to each other until we reach synthesis or exhaustion. This is the real wisdom of crowds, as Kathy Sierra so usefully points out, where individual and diverse opinions lead us to more collective understanding.
9 Comments
Nice post Anne - I’ve not seen any of these posts before you pointed to them - thanks.
Finally, some sanity in the blogosphere. It becomes enterprise-ready when folks stop ranting and can address each point. Regardless of whether folks feel others perspectives are valid, they need to focus on solving for them…
Taking McGovern’s productivity argument to the logical conclusion says that there has never been any improvement in productivity ever since the bad old COBOL days. This is clearly false, so new technologies must give performance improvements.
My take on it is, if your performance improvement is only 50%, sure, you can easily get swallowed up by all sorts of other factors, and a 50% lead now becomes a 10% lead. Especially if you spend all your time fending off people like McGovern.
Now, if you take a technology that gives you a 10x lead, then, even if you are nickelled and dimed to death, you can still kick some serious butt.
The other thing is, what exactly is McGovern saying? That change is bad? That change is your enemy? That we should be developing enterprise systems in C++ (we do at my work, it sucks, but no Java performance nightmares)? Or perhaps C and Cobol? Or what?!
Clearly Java and all its enterprise frameworks give you an edge on C++ and its… really awesome STL library. But have you tried to program in Java? The verboseness just kills me!
My current project is in erlang
-ryan
ryan: yes, you’re right, there are productivity improvements. Thinking more on it, I’d put it like this: in the short run, using a newer supposedly more productive environment will decrease your productivity (learning curve, integration headaches, etc.). In the medium term, it’s a toss-up whether you get productivity increases or decreases. In the long run, with truly more productive technology, you’ll see productivity improvements, assuming other factors don’t swamp you (like some acquisition or need for greater runtime performance or what have you).
Appreciate your comments, for sure… am enjoying the dialectic!
James: thanks, glad it came across as sane… found your position polemical, but not in a bad way; I’m not opposed to stating a position strongly. I’m learning a ton from your blog and getting a lot of traffic too!
Aye, I appreciated the thoughtful analysis of the sitaution, too. Until you started attacking 37S.
They (37S) have never called their practices “gospel”, nor their book a “bible”. Those are terms you’re introducing.
You also quote them out of context when you say:
“But HH’s response is not so shocking when you consider that he’s part of 37Signals, the firm that brings us the idea that ‘you shouldn’t write a functional specification document’ and that ‘functional specs subvert the hierarchy of nature.’”
Then you go on to say:
“I haven’t studied their Bible or prayed over it, but my sense is that their principles may work great for some Web 2.0 startups aiming at individuals and small to medium-sized businesses and not so well for situations of greater complexity.”
Well, it’s more than “your sense,” it’s along the lines of what they’ve stated many times; both in their book and on their blog.
They’re sharing principles that they believe in and have worked for them. However, they acknowledge that they may not work for you or your organization. Take what you will and leave the rest. No hard feelings.
I hope you write an equally thoughtful piece on blog revisionism.
If you haven’t heard yet, Mr. McGovern wrote an entry in which he stated among other things the Ruby doesn’t have regular expressions or instance variables. This proved he was not qualified to discuss Ruby at all.
THEN HE CHANGED HIS POST. He removed the proof that he didn’t know what he was talking about. Changing the points that proved he had never looked at a line of ruby into some other gibberish. Check the comments to see what he originally wrote.
The whole XP movement seems to be a drive away from engineering. I’ve been thinking about this for a little while.
I mean, those NASA dudes made the shuttle - without the help of modern super-computers-in-a-box (aka powermac G5! SWEET!). They planned everything, built it… and it WORKED!
But, now we can’t build a big enterprise system? No amount of planning works?
I guess maybe it does work… if you have NASA-sized budgets and timelines.
Software engineering - still a major work in practice. Struggling to love it. Stupid work
-ryan
The point is that one need not be COMPLICATED when dealing with COMPLEX problems.
To paraphrase Einstein: “As simple as possible, but no simpler”.
This is also my point.
Anne — am I hearing this right that you are in Colorado? Geez… I’m in Boulder now, still trying to figure out how to use an ice scraper and wondering why I need special “winter” windshield wiper fluid.
Please email me…let’s DO something!