December 7th, 2005 by Mark Ramm
Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite
There is a lot of good information in this evaluation of Ruby on Rails. Their preliminary work showed a roughly 20:1 Java to Rails code differential, and they claimed that the scalability for Rails was easier and better than Java.
It would be interesting to see how TurboGears would fit into this comparison, I think for simple applications there will be more code than Ruby on Rails, but not that much. But then for larger applications which could re-use a number of external libraries, I would expect the wealth of good Python libraries to begin to equalize or even tilt the LOC count in TurboGears’ favor.
November 30th, 2005 by Mark Ramm
Over on Planet TurboGears, Swaroop (author of “A Byte of Python“) asks: “Does Ruby on Rails really need the CREATE TABLE SQL statements to be written by hand?”
Well, as of a couple months ago, that would have been true, but now Rails has “Migrations” which are just as cool as the way all of us TurboGears folks have been doing it with SQLObject.
In fact, you could argue that migratins are a bit better in the way they handle incremental database upgrades both on the development and production side.
Right now this is not working as well as it should in TurboGears, and a couple people have reported problems with incremental schema updates. But I see that there is already a bug and a patch in the TurboGears Trac to fix the incremental upgrade problems people are having, so it should be fixed in SVN, but I haven’t had time to test it yet.
Anyway, I am excited to see these two great full stack web application frameworks getting better every day.
November 5th, 2005 by Mark Ramm
If your software where to go out on a date, would it be clean, well dressed, considerate, and engaging? Would it make it to the second date?
Creating software that users LOVE is hard for many programmers, as is dating. To me the interesting thing about this is that both activities are hard in the same way. Great software is sexy, and a great date is too.
I’ve definitely become a better software developer as I dated and eventually married my wife. Note, I’m probably not a better coder — but I get out of my own head and look at the software through my user’s eyes more often.
Anyway, hop on over to Kathy’s web page to find out how to make software that users love — and how to get more dates!
And for IT Mangers, this is a great way to talk to your programmers, QA people — everybody involved in software development — about usability. The more you talk about how sexy usability is, the more your team is going to remember, because people’s brains are wired to remember that kind of thing!
October 25th, 2005 by Mark Ramm
I will be hosting a free Ruby on Rails “tutorial and hack session” in mid to late November. This will be an intensive session for those who want to get up to speed on Rails quickly. We will learn the basics of Rails, and do some actual work on an Open Source app, so learning will be balanced by doing, and people should leave the session feeling pretty comfortable that they can move forward on their own.
Tentatively it will be from 10 am to 10 pm on the Saturday before Thanksgiving. I think 12 hours is long enough to get something significant done, but short enough that it won’t be totally mind-blowing. We’ll order out for lunch and dinner, so it would help if people could throw a few bucks into the pot to help me defray those costs.
But other than chipping in for food, and doing some work on an open source app, the whole thing won’t cost you a penny — at least for those who can bring their own computer. For those who can’t I believe we will be able to provide pre-set-up computers for you to use, but there will be a small fee to defray the costs of providing that service.
___________________________________________
Update: There seems to be enough interest, and I’ve found a place for us to meet, so the date is confirmed! We’ll be meeting November 19th, from 10 am untill about 10 pm.
October 18th, 2005 by Mark Ramm
I am giving a presentation on Rails at the Washtenaw Linux Users Group this week, so I thought it would be a good time to get a few ideas about productivity and Rails out of my head and down on paper.
I’ll post a link to the presentation later this week, but for now, I’d like to explore the big hairy audacious claim that’s been floating around there about Rails. People have said that they are 10x more productive in Rails than they were in Java, Struts, and Hibernate.
What makes this claim so controvercial is that it goes against the received wisdom that in software development there is no “silver bullet.”
So I thought it would be interesting to take another look at the 1986 essay that started it all No Silver Bullet by Fred Brooks. Which in my experience is much more widely talked about than read. I’d like to highlight one quote:
How much of what software developers now do is devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all the effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.
I think this gets to the essence of the problem. How much of what we do is dealing with the quirks and idiosyncrasies of the technology we use, and dealing with extraneous implementation details? The Lean Manufacturing side of my brain says we should probably be asking this question another way — “How much of what we do is Waste?”
If you follow the logic, what Fred Brooks is saying is not that an order of magnitude of productivity enhancement is impossible, just that an 10x improvement would mean that:
- 90% or more of what we do now is waste
- we can cut that waste to near zero
While they may seem like absurd statistics, I think both of them are often true.
Your customer wants working code — not meetings, detailed design specifications they can’t even understand, and bug lists!
Outside of IT, there are studies that show that many product development teams have %80 of their time allocated to non-value added activities. This is also true of software teams who spend time on status update meetings, communication planning, scope control, and training. And processes like CMM level 4 certifications often buy repeatability by increasing the burden of non “value-added” tasks.
Your customer doesn’t care how much code you produce, they just want software that works!
This gets us to the heart of the Rails proponent’s claim that using it can make you more than 10x more productive than you were in Java. This claim is based on the idea that even when you are actually sitting in front of your computer writing code, you there’s still waste that can be removed.
Ruby, Python, and Perl, as dynamic languages reduce some of the overhead of Java’s type system. And Rails reduces to near zero the effort required to keep the database schema, ORM code, and model objects in sync. Rails also reduces the mental overhead produced by non-intuitive naming conventions. So, there is certainly some real, and measurable improvement in programmer productivity just by moving to Rails.
The bad news, is that this isn’t going to make you 10x more productive. So far, the best study I’ve seen is shows that Rails has about %60 less code than the equivalent Java. If this is right it means you might be three times as productive in Rails as you would in Java.
Nice, but no silver bullet, right?
Well, there are also other benefits of working in Rails.
Since most Rails applications are developed by smaller smarter teams, there tends to be less team communication overhead on a rails project. Not only that but the nature of Rails development encourages incremental delivery, that removes a lot of waste in terms of over-specification, developing un-used features, and maintaining a complex scope control system.
Rails also includes easy ways to do unit and functional tests, which can significantly decrease the amount of time you waste finding and fixing bugs.
So, what’s the bottom line?
Using a dynamic language like Ruby means less code, which makes you faster. Rails’ full stack integration, means less code which makes you faster. Rails philosophy of convention over configuration means less XML configuration files, which makes you faster. Rails inclusion of a test environment by default, as well as a convenient unit testing framework means you are less likely to write buggy code — and that makes you faster too. All this plus the productivity gains from not having to communicate with a large team and the ability to easily do iterations, can definitely make you ten times more productive.
That said, you could probably get most of this from running another web development framework in a dynamic language, and working with a small team, and doing unit testing.
