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
Web apps are about web design. If your team is not experienced in Javascript, CSS, HTML, you must start by training them. Most developers think they understand web technologies because they already made some ugly simple application but when times comes of programming advanced Javascript and dealing with cross-browser compatibility, that’s a different story.
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
CTO at
Comments
Good article. I think you touch on more of the inherent problems with web development period. Agile development shouldn’t be just tied to Rails, it should be adopted across the board. I’ve been a strong supporter of this for years and through the various languages I’ve experienced (ASP, Cold Fusion, PHP, etc). What RoR does is makes it much easier. Same thing goes with web design skills, testing, overengineering etc. I think what Rails is driving at is we need to be thinking about all these thing more consciously.
One of the major issues I see with Rails is people who start on something like this and haven’t worked in more traditional scripting languages like PHP or ASP and haven’t really worked with HTML. Rails makes all this cool stuff happen kind of magically. But if don’t understand exactly what it’s doing behind the scenes there’s no way you can efficiently use it or extend it.
Another negative I’ve scenes with Rails thus far is I think with migrations it masks the database layer too much. Hypothetically you could create a complete database model and never once think about indexes, stored procedures, etc. Considering Rails relies so much on that database layer, I can see people having tons of performance problems when their database grows because they don’t understand this.
JP6 April 07 at 2:35 pm
It is really a good article… the most important point is we are lacking in TESTING…
Pavan Agrawal19 April 07 at 3:05 am
Hi Fred,
Thanks for that, very nice and concise. For every single point I can see who you are talking about in term of programmer.
IMHO, from my external experience on these very projects you are talking about, I guess you missed a point here : there were no proper project management. No clear milestones, no clear requirements, no clear targets, it was all too fuzzy, leaving developers on their technical own, in a kind of no mans land, without any proper vision of the product / deadline / requirement. And I guess that when there is no proper project management, there just cant be any Agile process in place.
Anyway, in the light of this, what is your current opinion about the current “Ruby can’t scale” debate (http://www.infoq.com/news/2007/04/twitter-contr…) ?
Funnily enough, this link also addresses your previous blog entry (twitter).
peace. c.
cecil dijoux20 April 07 at 4:15 am
[...] 5 Mistakes You Should Know before using Ruby on Rails in Your Company – On this post Frederic Brunel has shared experience about the difficulties that he has faced in the company he works for. It’s really worth to check this mistakes and beware of them. [...]
rubycorner.net - resources for ruby and rails development23 April 07 at 12:18 am
Hi Cecil,
I’m glad you keep reading my blog.
Concerning the point of management I guess you’re right, but unfortunately these two projects were not the only one to suffer from management issues — it was not tied to using Rails.
Within these projects I tried to do my best to guide project managers into defining small iterations with clear objectives. Unfortunately they kept trying defining all possible situation for the software and left developers with unanswered questions instead of focusing on steps.
It’s hard to make people think in terms of agile methodologies especially when the waterfall process is not even understood. They fall into a trap where defining the whole product was too complex and where prototyping should have been very helpful. Just too bad, but a classic story.
Concerning the Twitter debate you mentioned maybe I should reply in a separate post but anyway. Scaling is something complex that will change the shape of your hardware and software system, there is no magic and no automatic way to absorb such sudden peak of traffic. If you remember well, the architecture of the system we both worked on have been redesigned 3 times to cope with performance and load issues. Having used Java EJB or Oracle Clusters didn’t help that much regarding the nature of our application — we had to dig in the code and remove frameworks.
It’s no surprise that the Twitter team had to change and tweak the system to remove bottlenecks — that’s part of the job. Rails help you to put you app quickly on the market and that’s the most important. Scaling is a different step in the life of your application and chances are that you will always have to make tradeoffs whaterver the technology or framework you use.
Frederic Brunel21 April 07 at 2:50 am
Hi Frederic,
)
you are brave guy! I would not try to use the rails framework in enterprise for other stuff than prototyping… but it is probably a mental barrier of ex-enterprise architect
Cheers and good luck
Roman
Roman Mackovcak23 April 07 at 2:37 pm
Actually the suite of tools we built were only used internally and not open to public — except for some clients. We did not try to build a public web site or a service with it.
One thing I didn’t mention is that working with Rails gave a boost in motivation to the whole team; and we needed that.
Fred Brunel24 April 07 at 1:56 am
[...] 5 Mistakes You Should Know before using Ruby on Rails in Your Company – http://fredbrunel.com/journal/2007/04/5-mistakes-you-should-know-when-using-ruby-on-rails-in-your-company/ [...]
About RoR - Ruby on Rails « Junji’s Blog Site26 April 07 at 7:51 am
[...] 5 Mistakes done with Ruby on Rails A colleague gave me last week the link to Fredric Brunel’s excellent article : 5 Mistakes you should know before using Ruby on Rails in your company. [...]
5 Mistakes done with Ruby on Rails « Laurent’s Weblog29 October 07 at 6:45 pm
Frederic, you’ve posted an excellent article, in which i could retrieve what mistakes have been done on our project with RoR… I took your five points to develop theses mistakes : if you’re interested please check at : http://laurentbois.com/2007/10/29/5-mistakes-done-with-ruby-on-rails/
Laurent29 October 07 at 6:52 pm
Thanks Laurent.
Fred Brunel29 October 07 at 11:54 pm