I love how Mr. Atwood uses the metaphor of maintaining code as the ball o’ stuff from Katamari Damacy.
While I haven’t had the “pleasure” of working on a project that required a couple years and painstaking code refactoring, I can see such a problem coming into the picture if I am to tackle on a web application.
The fewer lines of code that ANYONE has to deal with, the better.
So many aspects of software development can be summarized as small is beautiful:
- The odds of failure for a software project are directly proportional to the size of the project. Slicing a large project into several smaller subprojects is the single most direct way to increase your project’s chances of success.
- The relationship between lines of code and bugs is completely linear. Fewer code means fewer bugs.
- Smaller code avoids TL; DR (Too Long; Didn’t Read) syndrome. The less code there is to read, the higher the odds are that someone will actually read it.
- If you keep your dependencies to a minimum, your code will be simpler and easier to understand.
Regardless of how Ruby on Rails might not scale, but I tend to agree with Mr. Stevenson.
Additional abstraction often takes more CPU time. But if you can get a Rails app up and running in a fraction of the time of another framework, and have a more stable base in the process, how much does the additional hardware cost really matter? I have exactly zero Rails apps deployed and running today, but I think that’s where my future development will be.
…
What if you’re given an option between a Rails app which takes a bit more CPU power, and an app written with another framework which never actually ships? I’ll take the slower version that exists over the efficient one that does not.
Now, I’m not so well versed in the world of optimizations on being able to install the best Ruby installation there is… nor do I know how the heck I can compare benchmark tests between Apache servers with different flags turned on while it was being compiled from the source.
Catch my sarcasm?
I’d like to think that I don’t have to. I’d like to think that Ruby will empower me with the tools to be able to do just about anything I want.
Anyway, I’m finally starting to go deeper with Ruby. I’m finding out that the why’s poignant guide, while fun, isn’t really the pragmatic way to go about learning the language. Just start with the short tutorials and start working up to the full blown Programming Ruby book.
Syntax is easy. Ridiculously easy. In fact, I think anyone coming out of a decent non-Java school (yes, Derek, that one was for you) should be able to pick up the syntax in a day. Now, mastering it… that’s another couple of weeks.
But alas, it’s not just about the practical. I don’t know… it must be my Apple fanaticism bleeding over into Ruby on Rails. After all, 37signals loves macs. And for me, they’re slowly creeping up on the “list of companies I’d love to work for”. Wow, that’s a post waiting to happen, isn’t it…