I have been spending some time researching Ruby on Rails, how it works, its development philosophy, and how it has affected web development, and will affect business in the near future.
The Ruby on Railsframework was released by David Heinemeier Hansson(it’s open source) in July 2004 has had a profound effect, and has been especially important in the development of the Web 2.0 movement.
Most importantly, Ruby on Rails simplifies the web development process through its “convention over configuration” and “Don’t repeat yourself” it fundamentally changes the role of the programmer in web development. Instead of asking questions like “How do I get function x to call method y?”, he is able to focus or how to do something, he is freed to focus more on the general business logic of the application.
This is why Ruby on Rails and the Agile software development movement go hand in hand. The Agile movement places a premium on human interaction and communication between programmers and business experts over software tools, process and methodology. The relationship between the Agile movement and Ruby on Rails is most clearly defined in the book Agile Web Development with Rails. Although the book is written for programmers, an intelligent lay reader and business person can also get a lot out of it, and understand the business implications of Agile development for web application development.
What does this mean? Basically, web application development as it is done by most businesses today is broken. Here are the two most common approaches:
- This is backend driven by database developers and developers who have good database and networking experience, and focus on creating the databases and tables, with little care, and often even less interest in the look and feel of the website. The most frequent result of this is a website which works fine on the functionality and business logic level but is butt-ugly. In projects of this kind the designers come in to mount rescue jobs, trying to turn a website only a mother could love into something which does not scare visitors away. In effect, the designers end up playing the role of the cosmetic surgeons in “Nip/Tuck”. Sometimes it works, often it doesn’t.
For a non-technical client more interested in creating a working application from the user point of view, this constant back and forth between client-side (front-end) design and backend programming throws them off completely from their established business goals. This is frequently made worse by the whole process: The client gives a brief then goes away, comps are submitted for approval by designers, then they go away, then the whole completed web application is shown to him, and he is expected to sign the check for the final payment with very little recourse if he is not pleased with the results, and all changes incur extra charges.By the time they have finished the project and made their final payment, they are often walking wounded.
Obviously, there is something very wrong with this development process. The designers get frustrated by limited client feedback until the project is nearly completed, the programmers get frustrated when the client changes the business logic, and the account people get frustrated at everyone, including the client.
This is what the Agile development process attempts to address. Basically, the client is asked to be fully engaged throughout the development process, sitting with the developers throughout and providing feedback all the while through while the developer is programming. The client can makes changes at anytime, and the website can even be tested in production mode to get user feedback, and more changes are made.
So how will Ruby on Rails change the role of the developer? It will no longer be enough for a programmer to be only a coder; a good developer will also have to understand business goals and user experience. With its emphasis on convention and process simplification, it is very likely that some of the best developers will come from client-side programming, while the best programmers will be those who have worked in business and understand business goals.
Does this mean that budgets for development will go down? In many cases it will probably be “yes”, but for developers who know how to understand communicate with their clients, and understand business, it’s more likely that their services will be especially in demand, and their fees will most likely go up.
Programming will be taken out of the lab, and it may well be that if you see two or three people sitting together over a notebook computer (most likely a MacBook Pro) in a cafe in Beijing, London or Pretoria, they are creating a new web application.