Rails only solves easy problems
Thanks for your attention. Now let me explain this. Ruby on Rails is a great application framework, Ruby having the best combination of power, shortness and readability. It’s more powerfull per line of code than Java and more readable than Lisp. Rails is probably the best tool for the job. But what job?
Application classification diagramm
There are different types of applications. To classify applications and find the right tools for a project, I’ve created an application classification diagramm (ACD). This ACD is based on my experiences and the relevancy of factors for my projects. Your company may have a different ACD.
The easiest projects are Webtop (1) projects. These are web and desktop applications including forums, blogs, wikis and other Web2.0 software. If you earn money through hosting such applications, your software is still in this category, but it has higher constraints for scalability and reliability. I mark those projects with a “+”. Examples in this category would be Digg in the standard and Rallypoint and Basecamp in the + category.
The next category are Business (2) projects. If you sell something through your application, then the application is a B application. For this category you have to think about laws and regulations which apply to your application. Bugs cost a lot of money or jail in this category. Examples in this category are eBay, Amazon or iTMS.
The next category are Realtime (3) applications. You could argue that realtime applications are easier than business applications, but I think from a development angle, real time applications pose higher constraints on your tools than business applications.
If you run money, your’re in a different camp and in the Money (4) category. No bugs there please. You don’t want a bug where 0.001% of the time 1c is lost. For money software there are also more security constraints and more laws and regulations than for business software in general. Your applications needs to correctly log everything, provide a high security level, store everything securely, prevent tempering with the data and enable audits. Examples are bank and stock exchange software.
The hardest category to write software for are Life (5) applications. Everytime human lifes depend on your application, it’s in this category. Examples would be nuclear power plant software, medicine applications or train management software.
Developer, inhouse or customer?
An orthogonal dimension to projects is the developer (D), inhouse (I) and customer (C) dimension. Tools are determined by this dimension too, though mostly this dimension depends on soft skills, role and process definitions. Deciding factors are who defines the application, what the application should do and who decides if the application does everything as defined. It’s easiest when the developer of the application decides what the application should do and if it’s fullfilling the specification. No communication overhead, no misunderstandings. The developer can very flexible change the goals and features. It gets harder when someone other then the developer decides all this, but the person is still inhouse. This happens with project managers, upper management, sales or marketing departments. There is more communication overhead, more people involved and more misunderstandings. The hardest projects are those where an external customer defines the application and decides if the application works according to spec. High communication overhead, unclear processes, conflicting processes, undefined roles, conflicting tools and no clear understanding of the goals happen all the time.
From my experiences with Rails and my experiences with the Rails community, most Rails projects are D1+ or I1+, with some projects being C2 or D2+. Most Basecamp projects seem to be either D1+ or I1+, with the free ones probably being D1 projects.
The size dimension
Some other dimensions are project size and the integration level. Some tools are better suited for smaller projects while other tools are better suited for bigger projects. So code size is a deciding factor for tool selection.
Some applications are standalone which means they don’t interface with other systems. Most often the only other software the application uses are databases. Database integration has been around for quite some time and is well understood, so I count database frontends as standalone. Integration projects usally need to interface with messaging systems, SAP and user databases.
This matrix is not optimal, as it uses lines of code (LOC) as one dimension. Languages differ a lot in the number of lines they need to solve a problem, Java needing much more than Ruby for example, DSLs and rule engines needing the least. A better metric would be number of classes, or number of methods, but coding styles differ here too. And for bigger systems LOC seem to describe the problems with the system more than other metrics.
Without knowing any number (I plan to do a survey on this in the future), I’d guess most Rails applications fall into the S10K or S100K range, with few projects being I100k.
There are other factors like “is the project from scratch” or does it extend an existing application, which could also be discussed.
Conclusion
There are different types of applications and you need different tools to develop them. Rails is an excellent tool for a special type of application. For other types you should use other tools. Does Rails only solve easy problems? Probably. But it’s not important if it only solves easy problems, but if it solves your problems.
You can leave a Reply here. Of course, you should follow me on twitter here.
