Rails - Apr 2005 - Justifying the use of Rails to a client

Hi,

Please excuse me if this has been asked in the past, but a hearty 
Google search hasn''t thrown up anything of use...

I''m currently pitching a project to a client for which I''d
like to use
RonR.  This would be the first time we''d have used RonR for a 
commercial project, and so I need to lay out a firm justification for 
the choice of development platform.

Are there any resources out there which provide some non-technical 
information on what RonR is and why it should be used?  Something I can 
present to a client to persuade them of the benefits?

Thanka,
-Phil

> Are there any resources out there which provide some non-technical 
> information on what RonR is and why it should be used?  Something I 
> can present to a client to persuade them of the benefits?
The way that I did it was by gauging how much more productive I was in 
Ruby on Rails than in PHP. Then, for example, I would tell them I could 
do the job in 20 hours with PHP or 2-3 hours in Ruby on Rails, it was 
up to them. Nobody has chosen PHP yet. You don''t have to charge less, 
just the faster turnaround is enough of an incentive for most people.

-Lucas
http://rufy.com/

> Are there any resources out there which provide some non-technical 
> information on what RonR is and why it should be used?  Something I 
> can present to a client to persuade them of the benefits?
1. Point to some of the big sites that rely on Rails. Basecamp, Tada, 
43things, Bellybutton.de, etc. That establishes the credibility that 
Rails is ready for prime time.

2. Explain that picking Rails will lead to either a cheaper project or 
a project with more features. Go with the productivity factor. You can 
find leads to anecdotal evidence in 
http://weblog.rubyonrails.com/archives/category/praise/

3. Tell them that an enthusiastic developer in love with his tools is a 
better, more productive developer.

4. Ask them to trust your expert opinion on what''s a good technical 
platform for this.

5. Calm down their fears of something "totally new" by pointing to the
many familiar names in the rest of the stack. Such as Apache and 
MySQL/PostgreSQL.

And don''t give up too easily. It''s in most clients nature to
reject
ideas of change. Heck, even I was getting pushback from my partner at 
37signals when I wanted to program Basecamp in Ruby. What a boring 
world we would have had if I had accepted his initial rejection as fact 
;)
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

On 4/13/05, David Heinemeier Hansson
<david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org>
wrote:
> > Are there any resources out there which provide some non-technical
> > information on what RonR is and why it should be used?  Something I
> > can present to a client to persuade them of the benefits?
> 
> 2. Explain that picking Rails will lead to either a cheaper project or
> a project with more features. Go with the productivity factor. You can
> find leads to anecdotal evidence in
> http://weblog.rubyonrails.com/archives/category/praise/
> 
I would concentrate on the productivity factor. You should present
your client estimates on how much effort a certain use case or user
story will take with ruby and with some other tool.

Try to be as concrete as you can. ie. how many days or hours would it
take to implement a feature, how many features would you be able to do
with X dollars. etc.

If you cannot provide (estimated) facts, you will have much harder
time selling it to the customer.

-- 
// heikki tunkelo

I''m just curious, how can you say that a 20-hour job in PHP is only
2-3 hours in Rails?  These must be pretty basic apps then.  Or maybe
I''m just slow :)

On 4/13/05, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org>
wrote:
> > Are there any resources out there which provide some non-technical
> > information on what RonR is and why it should be used?  Something I
> > can present to a client to persuade them of the benefits?
> 
> The way that I did it was by gauging how much more productive I was in
> Ruby on Rails than in PHP. Then, for example, I would tell them I could
> do the job in 20 hours with PHP or 2-3 hours in Ruby on Rails, it was
> up to them. Nobody has chosen PHP yet. You don''t have to charge
less,
> just the faster turnaround is enough of an incentive for most people.
> 
> -Lucas
> http://rufy.com/
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
rick
http://techno-weenie.net

Both hieraki and typo first versions where made in less then 6 hours each. 
First versions both had the essence of the application done and a
workable UI to boot.
In case of typo it implemented the complete metaweblog API spec, and
some of the time was
spent fixing ruby''s CGI module to live up to the task ( fix shipped
with rails now ).

Especially after building your own tools you can do most jobs
incredibly quickly. I tend to build
a lot of generators, even project specific ones. For example i have a
generator in snowdevil which
creates admin scaffold like controllers but with the correct design,
user authentication stuff already
in place. 


On 4/13/05, Rick Olson
<technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I''m just curious, how can you say that a 20-hour job in PHP is
only
> 2-3 hours in Rails?  These must be pretty basic apps then.  Or maybe
> I''m just slow :)
-- 
Tobi
http://www.snowdevil.ca - Snowboards that don''t suck
http://www.hieraki.org   - Open source book authoring
http://blog.leetsoft.com - Technical weblog

I doubt anyone here can build a production-ready non-trivial app in
2-3 hours in Rails or anything else.  But at least after 2-3 hours you
can see progress, and watch the clients breath a sigh of relief :)

(Not talking from experience...)

On Thursday, April 14, 2005, 12:00:04 AM, Rick wrote:
> I''m just curious, how can you say that a 20-hour job in PHP is
only
> 2-3 hours in Rails?  These must be pretty basic apps then.  Or maybe
> I''m just slow :)
> On 4/13/05, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote:
>> > Are there any resources out there which provide some non-technical
>> > information on what RonR is and why it should be used?  Something
I
>> > can present to a client to persuade them of the benefits?
>> 
>> The way that I did it was by gauging how much more productive I was in
>> Ruby on Rails than in PHP. Then, for example, I would tell them I could
>> do the job in 20 hours with PHP or 2-3 hours in Ruby on Rails, it was
>> up to them. Nobody has chosen PHP yet. You don''t have to
charge less,
>> just the faster turnaround is enough of an incentive for most people.
>> 
>> -Lucas
>> http://rufy.com/
>> 
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>

> Especially after building your own tools you can do most jobs
> incredibly quickly. I tend to build
> a lot of generators,

 Thanks for pointing this out.
 I too had a hard time connecting the dots on the productivity claims.
 It makes a little more sense, with customized generators.

I would guess,  a good understanding of Ruby , helps too.

What  else belong in the high-octane Rails toolkit?

emacs? 
Unix? 
fill in the blanks ....

-- 
Regards,
-Mark
http://leansoftwarecincinnati.blogspot.com/

On Thursday, April 14, 2005, 1:42:14 AM, Mark wrote:
>> Especially after building your own tools you can do most jobs
>> incredibly quickly. I tend to build
>> a lot of generators,
>  Thanks for pointing this out.
>  I too had a hard time connecting the dots on the productivity claims.
>  It makes a little more sense, with customized generators.
I don''t think the claims are based on, or dependent on, customised
generators at all.  People writing their own generator are surely in
the minority, but the majority of Rails users would appear to be very
impressed by the productivity it offers.
> I would guess,  a good understanding of Ruby , helps too.
Bingo.
> What  else belong in the high-octane Rails toolkit?
> emacs? 
> Unix? 
> fill in the blanks ....
Whatever you''re comfortable with.  Given that you need to edit a lot
of different files in Rails, a decent editor/IDE is a must.  I was
drooling over TextMate for Mac, but I''m a keen Vim user, and with the
project [1] and xmledit [2] plugins, I want for nothing.  Add a
Unix-like environment for general development cruft, and you''re
smoking.

But the productivity comes from Rails itself.

Gavin

[1] http://www.vim.org/scripts/script.php?script_id=69
[2] http://www.vim.org/scripts/script.php?script_id=301

I''m thinking Mac OSX, TextMate, and Caffeine.. of which I''ve
got 1.

You don''t necessarily have to pick 2 either :)
>  Thanks for pointing this out.
>  I too had a hard time connecting the dots on the productivity claims.
>  It makes a little more sense, with customized generators.
> 
> I would guess,  a good understanding of Ruby , helps too.
> 
> What  else belong in the high-octane Rails toolkit?
> 
> emacs?
> Unix?
> fill in the blanks ....
-- 
rick
http://techno-weenie.net

On 4/13/05, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org>
wrote:
> The way that I did it was by gauging how much more productive I was in
> Ruby on Rails than in PHP. Then, for example, I would tell them I could
> do the job in 20 hours with PHP or 2-3 hours in Ruby on Rails, it was
> up to them. Nobody has chosen PHP yet. You don''t have to charge
less,
> just the faster turnaround is enough of an incentive for most people.
Besides development time I think a very important point is the ease of
customizability:

- Rails enforces clean MVC separation, making it very easy to
customize your application''s looks without ever touching actual code
(and vice versa).
- Rails is built with Ruby, a very clean language that produces code
that not only pleases the eye but also the mind. You can modify and
refactor your application logic with very little effort.

Take care,
Hendrik

Thanks for all the feedback on this - this kind of help really warms me 
to the Rails community :)

I''m kind of fighting a battle on all fronts at the moment: not only am 
I trying to persuade non-technical people about the benefits of Rails, 
but also a Microsoft-based IT team to whom the word Apache is a 
swear-word! ;)

-Phil

Phil Powell <phil-ldtTreVRrIMcWVvVuXF20w@public.gmane.org> writes:
> I trying to persuade non-technical people about the benefits of Rails, 
> but also a Microsoft-based IT team to whom the word Apache is a 
> swear-word! ;)
Good thing Apache isn''t even the recommended environment for
Rails. :-)
-- 
doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org

On 4/13/05, Tobias Luetke
<tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Both hieraki and typo first versions where made in less then 6 hours each.
> First versions both had the essence of the application done and a
> workable UI to boot.
> 
This is exactly why i''m sure that railsday, the contest for seeing how
much rails develpment people can get done in 24 hours can be a
success.

It''s clear that real, useful, and functional applications can be
written in rails in a fraction fo the time you''d expect.

-rabble

I think this is a very good example of what not to tell the client.
They don''t want to hear these things. They all heard the same things
before about J2EE and
got burned. 

Stick with what DHH said. 

On 4/14/05, Hendrik Mans
<hendrik.mans-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 4/13/05, Lucas Carlson <rails-1eRuzFDw/cg@public.gmane.org> wrote:
> > The way that I did it was by gauging how much more productive I was in
> > Ruby on Rails than in PHP. Then, for example, I would tell them I
could
> > do the job in 20 hours with PHP or 2-3 hours in Ruby on Rails, it was
> > up to them. Nobody has chosen PHP yet. You don''t have to
charge less,
> > just the faster turnaround is enough of an incentive for most people.
> 
> Besides development time I think a very important point is the ease of
> customizability:
> 
> - Rails enforces clean MVC separation, making it very easy to
> customize your application''s looks without ever touching actual
code
> (and vice versa).
> - Rails is built with Ruby, a very clean language that produces code
> that not only pleases the eye but also the mind. You can modify and
> refactor your application logic with very little effort.
> 
> Take care,
> Hendrik
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Tobi
http://www.snowdevil.ca - Snowboards that don''t suck
http://www.hieraki.org   - Open source book authoring
http://blog.leetsoft.com - Technical weblog

We don''t even tell our clients which platform we will be building
their app in, and they don''t really care either. We don''t
bring the
subject up, and they care more about the functionality and such
things, than what tools we will be using to get the job done. They
probably like our speedy deliveries and/or feature rich apps, but they
don''t know or care about how we did it.

If we believed that using Rails, more so than any alternative, somehow
was a risk for them, we''d inform them about the tradeoffs of using it,
but we don''t. The only tradeoff I can think of about using Rails to
maintain or develop the app is that you have to hire a programmer of
at least average skill, instead of the neighbour''s kid, but
that''s not
even worth bringing up because we''re not their neighbour''s
kids.

Tomas

Hello all. I''m looking for feedback on the following:

What options does one have, as a company that produces software that is 
distributed directly to clients/VARs, when that software is built with a 
platform/architecture that uses a dynamic (non-compiled) language, and 
further, when that platform and/or language is open-source? This 
question qualifies for Rails and Ruby, but also it could hold for PHP, 
Perl, etc.

I''m interested not just in the general legal considerations (like 
licensing, intellectual property rights), but also practical 
considerations. For example, I could get an airtight licensing contract 
written for me, but if I have to hand the software to a client or 
vendor, they could easily turn around and get a team to re-sell it under 
another name (Pear PC anyone?). At least with designer bag knockoffs 
there is the latent pride on the part of the consumer of having the 
*real-thing* (albeit at 10x the cost). With software, if it walks like a 
duck and talks like a duck... who cares if it''s a rip-off? I could
force
the use of keys or certificates, but these are easily cracked even when 
the software is written in C++. This is less likely to happen in the 
ever-litigious US, but it''s a major concern for any company working 
internationally, where well-trained techies, cheap labor, and loose 
laws/enforcement abound.

If we wrote software in assembly it would still be a concern, but when 
there is little-to-no reverse-engineering needed for languages that 
don''t need to be compiled in the first place, it affects
decision-making
when selecting platforms/languages, which is rather unfortunate. With 
Java/.NET you can download a decompiler and have source code exported in 
a day. You can obfuscate, but that''s a small comfort; anyone with time 
and interest can figure that out. With dynamic languages, all the hard 
work is done for you.

If you are operating as an ASP (a la 37 signals with Basecamp), this 
isn''t much of an issue. However, if you have to give your software to 
*anyone*, whether a client to run on their own network, or to a 3rd 
party in general, what are your options?

This isn''t really a concern when dealing with smaller projects for 
smaller clients, where the compensation is based on project time, even 
if license it to them (as opposed to letting them own it). In those 
cases, PHP (and from this point forward RoR!) is usually the best 
choice, for all the reasons that we love (quick development, simple 
changes / customization). But when you''re licensing software that you 
own, the value - which at face value is the feature set and 
maintenance/support services - ultimately boils down to the source code, 
and needs to be protected to the fullest possible extent. Yes there are 
business models where the value is strictly your support (Red Hat, at 
least at first), but that''s not really what I''m asking about
(though I
welcome the comments).

This is something I''ve been curious about for some time, but PHP et al 
have never been attractive alternatives for larger projects. RoR is 
compelling enough that these concerns have escalated.

Any comments / sites / experience are welcome. Thanks!

Matt

> RoR is compelling enough that these concerns have escalated.
There has been a couple of threads on ruby-talk about how to encrypt 
your application by running it through some key-based encryptor.

In general, though, I don''t think its worth it. Or rather, I
don''t
think the alleged case of PearPC is enough to influence decision making 
like this.

Basically, just don''t deal with shady businesses. And if what appears 
to have been a clean business turns out to be shady, you shouldn''t have
too much of a problem informing their customers of their doings and 
pursue a legal route.

I think the number of companies that are interested in buying illegal 
software is probably pretty small. And in many cases, there''s probably 
not even much overlap between that group and your prospect customers.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

Since lighttpd doesn''t run on Windows, bad feelings about Apache
can''t
be a good thing for a MS-based shop if you want to run RoR.


Doug Alcorn wrote:
> Phil Powell <phil-ldtTreVRrIMcWVvVuXF20w@public.gmane.org> writes:
> 
> 
>>I trying to persuade non-technical people about the benefits of Rails, 
>>but also a Microsoft-based IT team to whom the word Apache is a 
>>swear-word! ;)
> 
> 
> Good thing Apache isn''t even the recommended environment for
> Rails. :-)
----------
Scanned for viruses by ClamAV

I thought that might be an issue with my firm, but my boss is open to
the idea of a linux server.  The only thing is I have to come up with
a good CMS to replace our ASP.Net one.

Though if we did move to linux/FreeBSD, I''d be a bit worried since my
*nix admin skills pale in comparison to my windows ones.

On 4/15/05, Kevin Williams <kevin-P4szbAuRZ8UqDJ6do+/SaQ@public.gmane.org>
wrote:
> Since lighttpd doesn''t run on Windows, bad feelings about Apache
can''t
> be a good thing for a MS-based shop if you want to run RoR.
-- 
rick
http://techno-weenie.net

I thought you could run LightHTTPD in a Cygwin environment. There''s
also COLinux (Linux environment runs as a Windows service)... Some
other people are working on getting FastCGI to work from IIS as well.
How well that integrates with RoR...?


On 4/15/05, Kevin Williams <kevin-P4szbAuRZ8UqDJ6do+/SaQ@public.gmane.org>
wrote:
> Since lighttpd doesn''t run on Windows, bad feelings about Apache
can''t
> be a good thing for a MS-based shop if you want to run RoR.
> 
> 
> Doug Alcorn wrote:
> > Phil Powell <phil-ldtTreVRrIMcWVvVuXF20w@public.gmane.org>
writes:
> >
> >
> >>I trying to persuade non-technical people about the benefits of
Rails,
> >>but also a Microsoft-based IT team to whom the word Apache is a
> >>swear-word! ;)
> >
> >
> > Good thing Apache isn''t even the recommended environment for
> > Rails. :-)
> 
> ----------
> Scanned for viruses by ClamAV
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Corey Lawson wrote:
> I thought you could run LightHTTPD in a Cygwin environment.
There''s
> also COLinux (Linux environment runs as a Windows service)... Some
> other people are working on getting FastCGI to work from IIS as well.
You can forget about Cygwin. It is better than using Windows only, but 
still has enough deal breaker quirks (at least for me) that I decided to 
give Colinux a try. Boy did I fall in love with that. You basically have 
a complete and native Linux environment running as a Windows service. 
With VNC you can even log in to an X-Server session and you the GUI 
apps. There are different distributions available. I use Debian, but you 
can certainly use others like Gentoo, Fedora, ...

Too bad there is no CoBSD

 > How well that integrates with RoR...?

Any Linux integrates very well with RoR since it is a viable production 
environment. You still need to have good Linux administration skills 
though, which can be a _huge_ thing if you don''t. Don''t
hesitate to
aquire some. It will be really rewarding if you do. The learning curve 
can be steep at times, but the possibilities are endless.

And look at it this way. Once you master Linux or a Unix like system you 
will be able to really enjoy your mac. (I said this only to appease the 
mac lovers, cause I don''t have one myself and don''t want to be
converted
_just yet_ ;) )

Sascha

I think the only thing about running LightHTTPD in Cygwin or CoLinux
is that you can''t get at SQL Server, right? Or can FastCGI running on
such a cohosted LightHTTPD call the Windows-hosted RoR framework and
executables, and thus invoke DBI::ADODB from within Windows?

Out of curiosity, has anyone had success with FastCGI+IIS+RoR?

On 4/15/05, Sascha Ebach
<se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org>
wrote:
> Corey Lawson wrote:
> > I thought you could run LightHTTPD in a Cygwin environment.
There''s
> > also COLinux (Linux environment runs as a Windows service)... Some
> > other people are working on getting FastCGI to work from IIS as well.
> 
> You can forget about Cygwin. It is better than using Windows only, but
> still has enough deal breaker quirks (at least for me) that I decided to
> give Colinux a try. Boy did I fall in love with that. You basically have
> a complete and native Linux environment running as a Windows service.
> With VNC you can even log in to an X-Server session and you the GUI
> apps. There are different distributions available. I use Debian, but you
> can certainly use others like Gentoo, Fedora, ...
> 
> Too bad there is no CoBSD
> 
>  > How well that integrates with RoR...?
> 
> Any Linux integrates very well with RoR since it is a viable production
> environment. You still need to have good Linux administration skills
> though, which can be a _huge_ thing if you don''t. Don''t
hesitate to
> aquire some. It will be really rewarding if you do. The learning curve
> can be steep at times, but the possibilities are endless.
> 
> And look at it this way. Once you master Linux or a Unix like system you
> will be able to really enjoy your mac. (I said this only to appease the
> mac lovers, cause I don''t have one myself and don''t want
to be converted
> _just yet_ ;) )
> 
> Sascha
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>