Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Recorded at:
Presented by Martin Fowler on Jul 12, 2009
Learning to be a Good Product Owner: Foundation Skills
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
If you can't stand listening to me droning - you can read the article of the talk.
Martin,
Has there been any sampling on whether the use of ruby is more advantageous in the creation/early stages of a project, relative to the later maintenance and upgrade phases?
Andrew
I am unable to get the video to play on Win XP, Firefox 3.5. It works in Chrome and Safari, FWIW.
I have updated my firefox to 3.5 and video is also not working in my browser.
First I would like to say that this was a nice talk and
that I enjoyed it greatly!
Martin presented his ideas clearly, and in case you never heard of him before
he is a UML and Agility hotshot, in a good way!
41 Ruby project by a reputable company is something any new technology can aspire
for, definitely good PR for Ruby and Rails
But the funny thing is, and if you think like I do, the bad things about Ruby,
which Martin highlighted in the talk are really, really, really terrible.
1. Ruby have a bad implementation.
Whats news to me was that Matz according to Martin doesn't have the skill to change this!
2. Ruby is slow.
But what you can read through the lines is , ThoughtWorks is trapped with 41, its a little too late to turn back to something else.
And the excuse that it's ok for a program to perform bad if it was written quickly seem hard to swallow.
OCaml at least one choice that offer high level abstraction and good performance.
3. He says that the bottle neck is the DB, and that they don't have the skills to fix this.
In many ways, Martin really admitted this in his talk, to defend Ruby's slowness he suggest that the problem and bottle neck are normally elsewhere like in the DB, and then he goes to say that mingle is slow! Which just means they don't know how to write fast DB applications, which is weird!
4. We deliver slow application to our customers! And they don't mind.
Presumably because they are delivered fast! Well, all I can think of is, they got lucky booking customers who are not demanding!
Personally I never met a customer who like slow application!
I do notice that number 3 and 4 and not really about Ruby, but what I am thinking is that they used Ruby to deliver these bad things. And they are tolerating it because of Ruby. Which at least fro me creates a bad association
Finally, all I wonna say is, after this talk, you might feel not so enthusiastic about Ruby.
Would not it have been better if he explained how he created fast performing application, and how his customers live the speed. And how speed in doing things changes perspectives and potential.
But he didn't, because they didn't!
I haven't done any sampling on that. I recall Mingle people saying that they certainly slowed, but were still faster.
In any application speed is a feature, but not the only feature that counts. After all I can write a really, really fast program if it doesn't have to do anything! So speed is something you trade-off versus other things.
On most of our applications the DB is the bottle neck, so Ruby's slowness isn't important. Mingle is an exception, but in that case they feel that rapid feature delivery is worth the need for more hardware.
This bug cropped up last week with all InfoQ videos and we are working to troubleshoot it. Some users have reported greater success in the meantime with IE (gulp). Floyd
A consulting company may do one or two projects when evaluating new technology. The fact that ThoughtWorks has done 41 projects (and counting) is an indication that this technology provides value to ThoughtWorks and their clients.
Ruby/Rails may not be the perfect fit for all projects and teams. I think the presentation provides provides good information for determining where, who and how to apply Ruby/Rails.
Is Ruby really slow? Have people tried Rubinius? Or other "performance-oriented" Ruby virtual machines?
I have a few more questions for you -
(1) Does the increasing popularity and maturing of languages like Clojure, change anything for your company's approach towards Ruby (because Ruby is slow)?
(2) Do you foresee TW using Lisp or Clojure or say, some of the functional languages in the near future?
So these seem to be the main issues identified when developing with Ruby on Rails: getting Active Directory (the built-in ORM) working with unit tests, more complex deployment mechanics, catching up with the platform's (particularly Rails) frequent updates, and, naturally, the Ruby/RoR learning curve.
The fact that Ruby on Rails has been indicated as a more productive environment than usual choices such as JEE or .NET in three years worth of projects, despite these issues, is certainly a great thing. It is difficult to see Ruby's slowness as an issue, since even Java was once like that, and look at how influent Java is in the enterprise market nowadays.
Regarding the learning curve, you mentioned that the teams were slow at the beginning (as expected with any new technology). Progressing through the "Improvement Ravine" had a relationship with their background on other scripting/dynamic languages and also with achieving the right attitude towards meta-programming. Perhaps I just didn't understand all the gathered data, but I could not visualize how steep this learning curve is. I think it would be really useful if you could provide some kind of feedback on this, and how it affected the teams' productivity at the early stages, this way people could have more realistic expectations on the outcome of adopting these technologies. How long until a JEE or .NET team can become productive on RoR?
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
12 comments
Watch Thread Reply