This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: Some of My Software Opinions Feed Title: Obie On Rails (Has It Been 9 Years Already?) Feed URL: http://jroller.com/obie/feed/entries/rss Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Obie Fernandez Latest Posts From Obie On Rails (Has It Been 9 Years Already?)

The following list contains some of my strongest opinions regarding software development, in no particular order. I suspect that they provide at least some context for my continued enthusiasm about Ruby on Rails.

• When it comes to delivering a successful project, developer motivation and productivity trump other factors.
• The best way to keep developers motivated and productive is to keep them focused on delivering business value.
• Performance refers to executing as fast as possible, on a given set of resources. Scalability, on the other hand, is about executing as fast as needed, on as many resources as needed. Performance is irrelevant when you can't scale. And if you can scale cheaply, then milking every ounce of processor power should not be your first (or even fortieth) priority.
• Scalability is a separate issue from choice of development tools, but linking the two issues together seems to be a pervasive mistake. There are many dimensions of scalability including the size of the user population, data-sets, and complexity, but a lot of enterprise software simply does not have extreme scalability requirements.
• Performance IS related to choice of language and framework because higher-level languages are easier to write and understand. There is consensus that the main source of performance issues in most applications is poorly-written application code.
• Convention over configuration is simply a better way to write software. Huge XML configuration files must be eliminated!
• Code portability, the ability to take code and run it on a different hardware platform is not particularly important. It's better to solve a problem well even if it only runs on one platform. Not solving a problem well increases the likelihood of failure, in which case portability is irrelevant.
• Database portability, the ability to run the same code on different relational database systems is even less important and is almost never achieved in practice.
• Presentation is very important, even for small projects. If your application looks bad, everyone will assume it is written badly.
• Allowing technology to dictate the approach to solving a business problem is usually a bad idea, however that advice shouldn't be used as an excuse to stick with inferior technology.
• The usefulness of generalized application components in the enterprise is dubious. Individual projects usually have very particular business needs and wildly different infrastructure, making parameterized reuse across the enterprise very difficult to achieve in practice.