Following a trackback to your own blog entry can be interesting from time to time. Today, for instance, I was led to an interesting blog from quite some years ago on the sys-con site by Michael Yuan entitled “Is Ruby Replacing Java? – Not So Fast”. In his blog, Michael talks a bit about why he thinks Ruby and RoR will not push Java out of the web application development arena. Part of his argument is that each development system tends to etch out a niche for itself, to attain dominance there and to be almost impossible to force out due to the traction it gathers in that niche.
His other argument, I think, is far more interesting and fundamental to the understanding of software engineering. To quote Micheal:
Instead, it matters far more to have better requirement gathering, better customer feedback, better development process, better trained developers, and better development tools (e.g., IDEs). In software engineering speak, the actual implementation of a system using a specific programming language has the lowest value in the value chain, and can be easily outsourced.
To put it another way (a way that I have tried to get many people to understand at different times):
It’s not about the language, people!!!
I’ve sort of talked about this before, from a different angle, in a previous blog. It irks me every time I hear somebody describe a language as being a better development platform than another language because of some feature that saves you somewhere between two keystrokes and two seconds worth of typing. Thinking that language A is a language-B-killer because of that sort of productivity improvement is a sign of inexperience, as far as I’m concerned. Reason being, when you get right down to it: writing software is about modeling. About constructing a useful, flexible, et cetera, domain model and supporting code. Software engineering is about all that plus more, like risk management, managing your team, ensuring communication within and outside your team, requirements management, change management, fill in your favorite feature. If you’re on top of all that, how the model is reflected exactly in the syntax of a language is almost an afterthought. And if you have to rely on the marginal productivity boosts you get from one language over another to save your neck, you might as well not bother.
Just to try and prevent the firestorm of misunderstandings that I know is coming my way: I’m not saying it’s not good to know how to do a particular thing in a particular language. Nor that knowledge of frameworks or a particular development system is not important. But I am saying that relying on
collection.each {|element| do_something.with(element)}(Ruby)
or
[f.c | c <- [1..M] ](Haskell)
over
for (Element e: MyCollection) { do_something(e) }(Java)
is just not going to make a difference and is no reason to think that one development platform is better than another. Meaningful productivity and flexibility come from a good design of your application. And, by consequence, from daring to refactor and redesign as necessary. Which means it also comes from having project management that is willing to support such development practices and defend them if need be. And from having developers (software engineers) who dare, who can carry off their practices and therefore can be relied on by project managers, enabling them to support and defend. Not from saving on a few braces here or there.
Thanks Michael, your blog is still a great read.