Last year, I wrote an article about How to Introduce Ruby on Rails in Your Company. My objective was to share with you the arguments I exposed to my team members to use Ruby on Rails for the next gen web-based tools in the company.
We had some good and bad times during development. I’d like to share with the 5 big mistakes we made during development, so you can be aware of some trouble if you really want to go further with Ruby on Rails.
One year has passed since I started the development of these tools. Unfortunately I left the company a couple of month ago and I waited far too long before publishing this article. I’ve decided to take some time to complete the draft.
As far as I can tell, we managed to deliver both tools and we succeeded in making these tools easier to use and with a better quality than other tools in the company.
The first tool is used to create and manage product catalogues for mobile shops. It’s bound to the mobile technology and the company business. We released a first version after last summer and the tool is now used daily. The other one is more an asset management tool. It is used by a mobile publishing team to store, retrieve and organize any kind mobile products.
The development was not as easy as expected but we did it. You have to be aware that it’s not easy to start with technologies like Ruby on Rails in a company with a traditional culture. You have to convince and control closely the development.
We made mistakes.
1 Lack of Agile Management
Rails and dynamic programming environments are more efficient coupled with an agile development methodology. If you stick with a traditional waterfall process, development will be as slow as usual. It was not very easy to make managers and developers understand how to start with designing interfaces first and make progress steps by steps.
I’ve also discovered that developers that read and talk about these technologies are not necessarily the ones that will help you to apply agile methodologies because they’re actually used to the traditional approach. Agile development is not as easy as it sounds. You will have to be in control so that developers — and managers — will be guided during the process.
2 Lack of Web Design Skills
3 Lack of Good Unit Testing Habits
Rails has a built-in unit testing framework, that’s part of the pros for using Ruby on Rails over other web framework. But you have to ensure developers knows how to implement unit tests in Rails and are actually doing the job.
When it comes to writing unit tests, excuses of not having enough time comes first. I’ve noticed that some developers spend most time toying with the framework because it’s new and fun. Keep them focused on implementing unit tests.
Unit testing is also part of the agile methodology, so it has to be clearly explained at the start of the project to all teams around.
4 Too Much Overengineering
We all know that Ruby is highly dynamic and that you could implement a lot of cool stuff. Be sure developers use Rails the way it was designed and are not fighting against the framework.
If you heard one of them say: “… Well, I had to rewrite that part because Rails did not support this and that…”, that’s a sign of overengineering. Not everything is implemented in Rails but I’m quite sure there is enough material for your business. Changing the framework will cost you time and will increase bugs.
5 Lack of Communication Among the Teams
In the enterprise world, developers are not alone. You have to deal with other teams around such as testers and IT department. You have to strongly communicate with these teams to be sure they understand what you will deliver: how it will be tested and how it will fit with the test pipeline; how it will be deployed and how it will fit in the production environment — Custom Apache deployments, Oracle DB support and UTF-8 are common problems.
Chances are that your testers and the IT department are not familiar with Rails so you’ll have to train them as well. Write a small application yourself to show them how it will be tested and deployed.
Good communication is also part of the knowledge transfer. You’ll have to ensure that other developers in the team — those that are not directly working on the Rails application — are updated with the development and well trained. They will have to take over the development one day or another.
Conclusions — how to increase your chances
- Be prepared to evangelize a lot — follow closely the project
- Adopt an iterative development
- Be sure everybody in the team has enough web skills
- Ensure that the IT team is aware of database and deployment requirements
- Don’t let other members of the team left behind — give updates and training