The Data Studio

On Rails

"On Rails" is an expression I first noticed with "Ruby on Rails". What does it mean?

Ruby on Rails is a very smart way of building a fully functional web application. The "on rails" part defines a load of conventions around the small decisions you would have to take if you were starting from scratch. Now that those small decisions are made for you, you can concentrate on the things that are important in your application.

It is a bit like using a CSS stylesheet for your website, a stylesheet that someone else has defined for you. The stylesheet define a standard look for your website: the fonts you use, the way you indent quotations, the way your tables look, all the things that you really do want to be consistent on your website anyway. You could achieve the same effect by specifying the format on every paragraph, every table, every table header, every table row, every table cell and so on. If you did that, some inconsistencies would creep in, when you forgot something small like aligning a particular text block for example. It is much easier to use a stylesheet: you just specify each of those little things once. You get better consistency and less code. When you decide to change something you do it once, in one place.

Ruby on Rails is a lot more than a stylesheet though; it is a whole way of working. You can customise the way your application behaves, but in most areas you just leave it to Rails and it does the right thing.

You could say that this reduces flexibility. It does, and that is a good thing. There are some places in your application where you want to be flexible, but there are very many small areas where you want to make the decision once and stick to it. You don't want to be configuring every table, every drop-down list, every interaction with the user, to behave differently from all the others.

The slogan "Convention Over Configuration" is another way of looking at the "on rails" principle. It says "let's develop conventions wherever we can; every time we we define a convention, then we save ourselves making the same decision over and over again".

For the programmer we save a load of work and for the user we give them less to learn and less chance to make mistakes. Similar things behave in similar ways so we don't have to think about how we get to the next field in a form, how we go back to the previous page, how we get help. These things always work the same way.

Ruby on Rails is a very comfortable environment to work in. You can create great applications and you can do so more quickly and reliably because you don't have to fuss about all the little things.

I want database programming to be like this. Ruby on Rails encourages you to use your database this way. I want to take that further and apply the same principles to the way we use databases whether we are programming in Ruby on Rails or not. I had been thinking about how to achieve this for some years, but it was only when Ruby on Rails came along that those ideas started to crystallise into everyday ways of working with databases. I owe a lot to David Heinemeier Hansson (the creator of Ruby on Rails), so this a big thank you.

Back in 2005, at the Open Source Convention, David Heinemeier Hansson gave a talk entitled “Secrets Behind Ruby on Rails”. He finished his talk with these wise words:

“Flexibility is over-rated.
Too many technologies are chasing flexibility as [if it were] free. It is not. […]
Rails trades flexibility and gets a whole lot in return […]
Constraints are liberating.
When you don’t need to worry about all those small things and can just follow a path, you get to worry about your business logic, the stuff that your application is actually supposed to do.”

In 1975, before David Heinemeier Hansson was born, and when I was just getting started in my career, another very smart man called Fred Brooks wrote The Mythical Man-Month. In this book, Fred Brooks describes what he calls "conceptual integrity". He says:

“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.”

To me, these ideas are closely related. I don't wish to detract from either of them by saying that; both men made perceptive, original and hugely important observations about the way we work. Both contributed to better productivity and a better experience of technology for developers and users. They are similar because they put the emphasis on doing one thing well, rather than adding more and more features.

Commercial pressures tend to act against the "on rails" priniciple and against "conceptual integrity". The "fully loaded" label sells cars and pizzas, and it sells software too. This works because software sales people are trained to sell to managers and to cut users and technicians out of the process. The manager usually thinks more stuff is better, so he goes for the "fully loaded" option. The manager gets backup from Gartner with its "completeness of vision" rating (which has been carefully nurtured by the software marketing team). The sales person therefore pushes the product manager for more features and the product manager defines what goes in the next release. It is a dumb process and there are very few software developers who are brave enough to say "no". These few do build the best products though and sometimes those shine through.