Subject: [LONG] Re: How to convince a manager to use Ruby & Rails?
Newsgroups: gmane.comp.lang.ruby.rails
Date: 2005-08-22 01:28:43 GMT (2 years, 45 weeks, 2 days, 8 hours and 2 minutes ago)
Nicolas, Sounds like you were in exactly the same position as I was with our first Rails app. In my situation our boss asked what we could use to replace VB and MS Access applications that were going the way of the Dodo Bird soon. In my case it wasn't that hard of a sell since I proposed we spend one month doing a pilot project to see how much we could get done. Turned out we did the entire project's functionality in about 2.5 weeks so it turned into a big win for us. The general strategy I proposed to the head honchos is that we use Rails for small quick agile applications with a small number of users and then leave the established Java stuff to the big applications. This is a total farce though as Rails can handle all the same stuff if not more than Java (and I've proven this time and again with consistent statistically based performance metrics). The big things I can recommend you hit in your presentation are the following: 1. Seriously propose a range of alternatives--including continuing with the current platform--and present the pros/cons of each. They can smell when you're "stuffing the ballot" so be honest. For example, have you considered just pointing Brio, Cognos, or similar tool at your data? 2. Plan to handle the following questions: * "What about security?" * "How well does it scale?" * "What's the performance (see below) like?" * "How many users can it handle?" * "How would we deploy it?" * "Do we have the hardware to support it?" * "How does it fit into our current deployment setup?" * "What happens if we have to reboot the server?" * "Is it robust enough to handle our complex business needs?" 3. Give some anecdotes from other sources about the efficiency of Ruby on Rails, and also present the alternative rebutals from similar sources. 4. Demonstrate the #1 thing that Rails has over nearly every other framework: Native Ajax support. I'd take the time to whip up a simple "Ajax Demo" that showed off the cool stuff you can do with Ajax. Other platform advocates will have a hard time competing with that, especially if you show how most Ajax in Rails involves about 10 lines of code (if that). 5. If you're not good at making cheeze charts (powerpoint to biz people) then get ahold of a friend from marketing to help you out. Buy him/her lunch and they'll probably kick in some assistance. Especially if they can put their name on the proposal and win some cool points. Just be careful they don't stab you in the back and try to take credit for the idea (depends on where you work). Finally, here's some common answers to the questions I gave above: * "What about security?" -- Rails, being a web application framework is just as secure as every other framework. It provides all the normal features for AAA (Authentication, Authorization, Auditing) such as LDAP, logging, etc. and has the same weaknesses if used by uneducated developers. (It helps if you can find a piece of previously written vulnerable or bad code from the other frameworks). * "How well does it scale?" -- First, get them to define scalability. If they say, "You know, how many users can it handle?" Then be prepared to educate them that scalability is about being able to start small, and expand later, not about how many users a given system can handle. *That* is performance. Once you've nailed that down, tell them Rails adopts the "share nothing" idea so you can easily scale it out by adding more hardware and running more Rails. This is in contrast to complex Java App server deployments which require MQ systems, NFS, complex session shuffling, and lots of software just to scale. * "What's the performance like?" -- Tell them it performs just about the same as other platforms, sometimes better, sometimes worse. The advantage that Rails has over many other architectures is that it's simplicity makes it easier to tune and (drumroll) scale to meet performance needs. In addition, say that if they can come up with solid performance requirements, then it'll be possible to kill the project early if Rails can't meet the needs. The nice thing about this last strategy is that they are now on the hook to develop a set of metrics which you can then verify against existing systems. For example, they say, "It needs to handle 500 connections/second." Don't let them say "users", "users" means nothing. Then you go test their current WizBangOMatic and find it only handles 10 conn/second. You can then come to them and say that Rails can't do 500 conn/second, but it can do better than the WizBangOMatic which only has 10 conn/second performance. It's evil, but it puts the performance harpies at rest. * "How many users can it handle?" -- See performance. In addition, "users" is a very vague term you can't measure. You can measure requests, connections, bytes transfered, simultaneous connected clients, but not users. * "How would we deploy it?" -- Explain the software needed, platforms it runs on, how well it runs on them, etc. * "Do we have the hardware to support it?" -- Yes, it runs on nearly everything, and more than Java. * "How does it fit into our current deployment setup?" -- This one is up to you. Figure it out because they'll ask. * "What happens if we have to reboot the server?" -- Reboot it. You can configure Rails to start up on reboot just like any other piece of software on the planet. * "Is it robust enough to handle our complex business needs?" -- Explain that several businesses are basing their lives on Rails, and that it seems to be as robust as every other software system. Good luck. On Sun, 21 Aug 2005 20:53:17 +0200 Nicolas Buet <nicolas.buet@...> wrote: > Hi, > I understand that this might be off topic, but it's still rails related. I > have a meeting tomorrow with a manager about a database front end project. > He want to use jdbc, but for a change I would like to use rails. What do you > think could convince him that Rails is a viable choice? > (I don't know much about the project, but it is small: 5 weeks from design > to delivery, 3 users or less, no authentification... this will replace a "ms > access" tool) > Regards, > Nicolas >