Explaining to existing customers why you are developing with Rails now instead of .NET
Michael Breen
- Why Rails?
I really don't have the simple answer for this that the clients are looking for. I don't dislike or have any animosity towards Microsoft. I have a lot of respect for what MS is trying to accomplish. I just don't want to use their tools anymore. Using Rails just *feels* right to me. It's in sync with the way I want to write code. I really wish I could come up with a better explanation because I get the feeling that my clients are looking for answers along the lines of "Rails performs better than .NET", "Rails is more secure than .NET", blah blah blah. I just don't want or see the need to get into that. I just want to say "Rails helps me be a better developer". I have long tried to incorporate Agile methodologies into my day to day .NET development but it always felt forced and uncomfortable. I know there are many developers who do practice Agile with .NET (the crew at CodeBetter.com comes to mind) but it always been hard for me. This probably says much more about my skills than .NET. I am not saying that one can't develop .NET applications using Agile, I'm saying that I can't.
- If Rails is so great why didn't you develop our solution using it?
Some clients feel like I have shortchanged them or built an inferior product because it was done in .NET. I don't feel this way. I believe that .NET is a great platform to build an application on. The only answer I have is that at the time I was not confident that I could deliver a stable Rails app that would meet the requirements. Some clients think I took the "easy" way out and just sold them a .NET solution.
- Should I convert my current app to Rails?
My answer is always an emphatic "No". How can I explain that .NET is fine platform for applications while at the same time saying I no longer want to develop solutions with it?
Thanks for the help.
Mike
Wes Gamble
I totally understand what you are saying here (for me, replace .Net with
Java). A lot of factors influence the choice of platform, including the
ability to find people to maintain it, and the ready availability of
support. The .Net and Java ecosystems are just bigger than the Rails
ecosystem is at this point, so going with those platforms is a
respectable decision for many organizations.
Personally, I think that the choice to use Rails has to do with
professional evolution and the desire to be able to serve your clients
better in the future, by being able to delivering solutions of high
quality in a reasonable time.
Wes
Mitch Pirtle
As such my answers are fairly PHP-centric, but with modification
might be of some reuse ;-)
On Jul 28, 2007, at 14:20 , Michael Breen wrote:
> - Why Rails?
Your .Net-flavored answer was great, here's a PHP-flavored one:
Because Rails is today where PHP wants to be in a couple years, and
waiting just makes no sense to me. Rails gives you testing, revision
control integration, change management, and a host of other things
that you just can't get without significant effort in PHP-land. I
*love* PHP, but the more time I spend doing Rails work the lower that
PHP flame burns. Rails makes it possible for the developer to
actually develop, instead of constantly fiddle with their
environment, manually implement change management or other
operational features, etc.
Last resort: If it seems like all the hot "Web2.0" websites are
built on Rails, there's probably a reason.
> - If Rails is so great why didn't you develop our solution using it?
Look, I'm a New Yorker, and New Yorkers are ALWAYS fashionably late -
even if we seem to move faster than everyone else.
Seriously, my answer to that one is that I've been watching Rails
evolve and mature, and it's at a point where I am confident using it
for serious business.
> - Should I convert my current app to Rails?
Only if it is severely broken and has more than 50% of the features
waiting to be implemented. I'm in the process of one migration right
now, and am learning while I go that it is quicker to re-implement in
Rails than to refactor the existing code (in this case, a PHP
application).
-- Mitch
Warren Seen
>
> Going through the same experience here, but in a white-hot PHP world.
> As such my answers are fairly PHP-centric, but with modification
> might be of some reuse ;-)
Mitch, I like your answers!
When I talk to other developers about why I'm getting out of PHP, I
tell them that in a few years, Ruby and Rails (and arguably Python/
Django) will be to PHP what PHP was to Perl/CGI a few years ago ;-)
People aren't going to stop doing PHP, but in my view the bigger,
more complex projects will move to more rigourous frameworks .
Many of my clients don't have the historical perspective that we as
developers do, so it's difficult to convey this evolution as
succinctly, but frankly they shouldn't have to care about the
platform, but rather the results it allows me to deliver. I tend to
focus on rapid delivery and the economic benefits of using Rails due
to all the "stuff you get for free" that you used to need to hunt for/
roll yourself in PHP. Most of my projects are small enough that
they're never going to hit performance/scalability issues, so
although Rails may be slower at runtime than other platforms, the
performance tradeoff for faster (read: cheaper) delivery is a no-
brainer.
The only occasional hiccup we seem to run into is at completion, in
relation to the client finding competent Rails hosting within their
budget, there can be a little bit of "sticker shock" when you compare
to PHP hosting, which has really become a commodity market. I imagine
however this will resolve itself in time as more budget hosting
options become available.
Cheers,
Warren
----
Warren Seen B.Comp(Hons)
Software Developer
ruby on rails programming, web application development and software
consulting.
+61 417 264 329
war...@warrenseen.com
www.warrenseen.com
Robby Russell
On Jul 29, 2007, at 6:29 PM, Warren Seen wrote:
>
> On 30/07/2007, at 7:46 AM, Mitch Pirtle wrote:
>
>>
>> Going through the same experience here, but in a white-hot PHP world.
>> As such my answers are fairly PHP-centric, but with modification
>> might be of some reuse ;-)
>
>
> The only occasional hiccup we seem to run into is at completion, in
> relation to the client finding competent Rails hosting within their
> budget, there can be a little bit of "sticker shock" when you compare
> to PHP hosting, which has really become a commodity market. I imagine
> however this will resolve itself in time as more budget hosting
> options become available.
I really hope that budget hosting isn't going to become more and more
available. Why? Because it's very concerned that people will shell
out tens/hundreds of thousands of dollars to design and develop their
business web site and then want to stick it on a $10/month hosting
plan to save money.
As someone who has been running a Rails hosting business for 2 1/2
years... I've seen this sort of thing happen more than I'd like to
admit. Even worse, I've had discussions with these people and have
long conversations explaining that it's not a "short-coming" of Rails
that they should pay at least 7x/month for reliable hosting compared
to PHP. I tend to try and explain that comparing PHP to hosting Ruby
is like apples and oranges. A much more accurate comparison is
hosting a Java/Tomcat app to Ruby/Rails or a .NET app.
In my opinion, budget hosting might work for the hobbyists, but
businesses that rely on their website should be discouraged from even
considering economy grade hosting, especially if the hosting company
"just added" Rails support on top of their existing economy PHP
hosting. If you guys are selling Rails to people, manage their
expectations on hosting costs early on. Otherwise people like me have
to explain it after they've gotten "sticker shock" and this isn't any
good for the reputation of Rails. It's often an easy enough to
discussion to explain, up front, "Rails will cost you a bit more to
host, but you'll save so much money in development and maintenance
costs." For many of us, I'd imagine a hour of our consulting/
development costs more than what a monthly expense would cost the
projects we work on.
Just my two cents on this topic... :-)
Robby
--
Robby Russell
Founder and Executive Director
PLANET ARGON, LLC
Design, Development, and Hosting with Ruby on Rails
http://www.planetargon.com/
http://www.robbyonrails.com/
+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]
Warren Seen
On 30/07/2007, at 12:07 PM, Robby Russell wrote:
>
>
> On Jul 29, 2007, at 6:29 PM, Warren Seen wrote:
>
>>
>> On 30/07/2007, at 7:46 AM, Mitch Pirtle wrote:
>>
>>>
>>> Going through the same experience here, but in a white-hot PHP
>>> world.
>>> As such my answers are fairly PHP-centric, but with modification
>>> might be of some reuse ;-)
>>
>>
>> The only occasional hiccup we seem to run into is at completion, in
>> relation to the client finding competent Rails hosting within their
>> budget, there can be a little bit of "sticker shock" when you compare
>> to PHP hosting, which has really become a commodity market. I imagine
>> however this will resolve itself in time as more budget hosting
>> options become available.
>
> I really hope that budget hosting isn't going to become more and more
> available. Why? Because it's very concerned that people will shell
> out tens/hundreds of thousands of dollars to design and develop their
> business web site and then want to stick it on a $10/month hosting
> plan to save money.
>
I think we're coming at things from two different perspectives here:
my clients don't have a budget in that order, so any savings they
make in having me develop something for them in Rails instead of PHP
could be clawed back in higher hosting costs in as little as 18
months. Never mind that to us there is a difference between PHP
hosting and Rails hosting - they don't care, all they see is an
ongoing cost and want to know why one is higher than the other. If
the Rails solution is going to end up having cost them more than PHP
2 years down the track, it's not hard to see which way they'll go...
Naturally, you get what you pay for, but I'd like to see some entry-
level shared hosting around the AU$30-40/month price range for small
and micro-biz clients to get started on - I would consider that
"budget" hosting. While it might seem like quibbling over a few bucks
to us, who am I to tell a client how to control their costs? If they
want to save a few bucks with budget hosting, that's their
prerogative and all I can do is warn them of the potential trouble
down the track. Those who are serious about things will very quickly
see the benefit of investing in a decent host the first time they get
burnt.
Cheers,
Warren.
Robby Russell
On Jul 29, 2007, at 8:41 PM, Warren Seen wrote:
> . While it might seem like quibbling over a few bucks
> to us, who am I to tell a client how to control their costs?
You're the consultant that they hired to give them good advice. As
long as they are made aware of the pros/cons before they make their
decision.
When it comes to our clients, we have a lot of business-related
discussions about their growth plan, because I want to make sure that
when we finish our job, that they're in good position.
For example, I would probably beg a client to reconsider hosting
anywhere where they would be running an application that we built
through apache + mod_fcgi. ;-)
-Robby
--
Robby Russell
http://www.robbyonrails.com/
http://www.planetargon.com/
Warren Seen
On 30/07/2007, at 2:28 PM, Robby Russell wrote:
>
>
> On Jul 29, 2007, at 8:41 PM, Warren Seen wrote:
>
>> . While it might seem like quibbling over a few bucks
>> to us, who am I to tell a client how to control their costs?
>
> You're the consultant that they hired to give them good advice. As
> long as they are made aware of the pros/cons before they make their
> decision.
Yes, I used "tell" in the sense of dictating to them, rather than
advising them :-) I will advise against really cheap and crappy
hosting until I'm blue in the face, but it's ultimately their
decision, and their chequebook/credit card. There are always going to
be clients who are happy to suffer along with cheap hosting, and
spend the other $80/month elsewhere, they can't justify spending the
same amount on hosting as a project with 5 or 10 times the budget
would, because to them, it's a significant ongoing cost in proportion
to their budget. It's unfortunate, but that's the reality in which I
have to operate :-)
>
> When it comes to our clients, we have a lot of business-related
> discussions about their growth plan, because I want to make sure that
> when we finish our job, that they're in good position.
>
> For example, I would probably beg a client to reconsider hosting
> anywhere where they would be running an application that we built
> through apache + mod_fcgi. ;-)
>
Been there, done that - most listen, but like I said, people who make
decisions like this ultimately get burnt, and learn that it's worth
spending that bit more on their hosting. :-) I still think there's a
demand for small- and micro-biz hosting needs that is under-served,
between the cheap and nasty tacked-on $10/month stuff, and what you
guys are doing at Planet Argon. Whether there's a business case for
it from a hosting perspective, I can't say.
Sorry for pulling this discussion off topic...
Cheers,
Warren
Charles Cooke
with support of their applications?
Obviously, it's not feasible for us smaller guys to provide 24x7
support. However, most of the 'good' hosting sites do advertise 24x7
(usually email) support.. how do we explain the difference between
having 24x7 hosting support and 24x7 application support? I don't want
to mislead customers by having them believe that their application is
supported 24x7, but I would like to make it clear that there is a huge
cost to supporting a custom application 24x7.
Or should I just bite the bullet and get more revenue so we can afford
this? :)
Eric Anderson
On Jul 28, 2:20 pm, "Michael Breen" <hard...@gmail.com> wrote:
> - Why Rails?
I don't go into all the great aspects of Rails. I just keep it high-
level. Usually something like:
We develop applications using the technology that is currently the
best of breed. Rails is currently that. It has all the things
developers like to get our job done efficiently (cheaper development
benefit) and is a firm foundation to build an application on that will
last many years. Will it always remain the best? Probably not. But for
now it is and for many years to come it will at least remain very high
up there.
> - If Rails is so great why didn't you develop our solution using it?
For this I usually focus on giving technology time to mature and
giving my own development shop time to understand how to leverage to
technology for our clients. Usually something like:
"When we developed your application in Java/C#/PHP, Ruby on Rails was
still just maturing. We were testing it out for internal stuff and
found ourselves submitting patches back to Rails just to get what we
wanted developed done. Also our knowledge on how to leverage this new
technology was not very developed. Now we have lots of experience and
understanding with the technology and the technology is very mature.
At the time we developed your application Java/PHP/C# was the best of
breed. Although still quite good and still it will still be at the top
for many years to come it is no longer at the top. This is OK and just
the normal course for technology.
> - Should I convert my current app to Rails?
Depends on your needs. This is kind of like asking should I buy a new
car or fix up my old one. Obviously a new car will have a lower
maintenance cost and be more reliable. But you still have the cost of
a new car payment. For the cost of that new car payment you can fix a
lot of stuff on your existing car and keep it running for many years
to come.
This is a judgment call and depends on your needs. If you think you
will do significant work on the app in the coming months then maybe it
would be good to restart on Rails taking with you what you learned
about the problem domain (so the old project wasn't a waste by any
stretch of the imagination not to mention the years of use you already
have out of it). On the other hand no matter how good the technology
is it will always be expensive to rewrite a project. You can get a lot
of "fixes and adjustments" done on the old app for the cheaper price.
I have a app that I am still actively maintaining written in Classic
ASP in 2001. It is built around a framework built in 1998. I cringe
everytime I work on it because the smallest things take so much time
compared to anything written recently. But on the flip side it would
probably cost $20,000 to rewrite that in Rails. They are currently
spending between $500-$1000 a year maintaining the old app. $1000 is
much cheaper than $20,000 and they can probably continue to do that
for another 5 years before they might be forced to consider a rewrite.
Would I like a clean start? Yes! Does it make business sense? No!
Paul Robinson
> I don't want to mislead customers by having them believe that their
> application is supported 24x7, but I would like to make it clear
> that there is a huge
> cost to supporting a custom application 24x7.
Offer an SLA:
1-working day reposnse = x
Working day 4-hour response = 2x
Working day 1-hour response = 3x
24x7, 8-hour response = 5x
24x7, 4-hour response = 10x
24x7, 1-hour response = 20x
Obviously tailor for your situation, but if the customer is prepared
to pay for it, let them. Just reassure the ones at the lower end of
the budget scale that 999 times out of 1000 a 1-working day response
is fine.
--
Paul Robinson
Software R&D :: Unix/Linux :: Consultancy :: Open Source :: Comms
http://vagueware.com :: pa...@vagueware.com :: +44 (0) 7740 465746
Vagueware Limited is registered in England/Wales, number 05700421
Registered Office: 3 Tivoli Place, Ilkley, W. Yorkshire, LS29 8SU
Correspondence: 55 Velvet Court, Granby Row, Manchester, M1 7AB
David
Have you ever had a client actually "purchase" one of these SLA's? I'm just wondering how you deal with your real life if you have to offer 4 hour or less response.
I would think you would need to have a backup so that you could go on vacation, doctors office... I know that I wouldn't want that type of pressure on my (for any amount of money), so I probably wouldn't offer the service.
Just my 2 cent forth.
- David L
tmor...@gmail.com
> This brings up another interesting point - how does everyone here deal
> with support of their applications?
>
> Obviously, it's not feasible for us smaller guys to provide 24x7
> support. However, most of the 'good' hosting sites do advertise 24x7
> (usually email) support.. how do we explain the difference between
> having 24x7 hosting support and 24x7 application support? I don't want
> to mislead customers by having them believe that their application is
> supported 24x7, but I would like to make it clear that there is a huge
> cost to supporting a custom application 24x7.
>
> Or should I just bite the bullet and get more revenue so we can afford
> this? :)
Of course it depends on what you mean by application level support.
At Engine Yard we've chosen to go deeper into the support stack than
is typical for most hosting companies.
We have many developers who have chosen to host their customers' sites
with us so they can sleep at night, knowing that we'll fix things that
go wrong while they're dreaming.
Rails made this decision possible by convention over configuration.
Rails++ :-)
--
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Support, Scalability, Reliability
-- (866) 518-YARD (9273)
Mustafa
it is said that interaction design should come first. that is, how the
actors of the system interact with the system. it is okey.
then comes the specifications.
I wonder how u write specifications. How much detail should I put into
it? May be some of you can send me some real examples of your work.
then comes the underlying database structures and code which pass the
specifications. that means the specifications are very vital.
I feel like I am on the correct way guys :)
thanks in advance
Mustafa Ekim
Istanbul - Turkey
Paul Robinson
Have you ever had a client actually "purchase" one of these SLA's? I'm just wondering how you deal with your real life if you have to offer 4 hour or less response.
Rafael George
fair, I mean, you said that PHP wants to be where Rails is right now,
but why don't you compare Rails with Symfony/CakePHP/Zend Framework.
I know this mailing list is a about Rails bussiness, but we have to be
objetive in some spots.
And talking about last resort, i don't think the hottest web2.0 apps
are written in Rails, Facebook comes to mind, anyway clients just want
to see results and Rails give them that very quickly most of the apps
are scalable so when they come again asking you for a new feature you
will always deliver that in 2 or less hours.
--
Grimoire Guru
SourceMage GNU/Linux
Mitch Pirtle
>
> The comparation between a programming language and a framework is not
> fair, I mean, you said that PHP wants to be where Rails is right now,
> but why don't you compare Rails with Symfony/CakePHP/Zend Framework.
My apologies, I thought it was implicit that I was talking about frameworks.
One thing that I have learned is that Rails + Capistrano + RSpec
provides something that the PHP frameworks cannot do without
significant additional effort. I'm a huge fan of Phing, for instance,
but building a PHP (framework) app and integrating it with Phing is a
lot of work. Then there's working with PHPUnit versus RSpec and so on...
Ultimately I've learned that development the "Rails way" gets me up
and running in a shorter amount of time, provides a significant amount
of additional capability, and requires less effort to both work with
and maintain.
Again, sorry to have been too short with my choice of words on the topic :-)
-- Mitch
Michael Breen
I didn't want this thread to turn into a battle about which OS, hosting service or framework reigns supreme. Those topics have been beaten to death elsewhere. I was really looking for some advice on how to explain a change in business practices to your existing customers. It's my fault for not phrasing the question that way and dragging .NET into the discussion. I should have put my thoughts down before firing off a message to the group.
For those of you who offered advice I really do appreciate it. This group has been a big help.
Thanks.
Mike
Greg Pederson
I'm in the US Eastern time zone.
Greg
Quis custodiet ipsos custodes
Greg.P...@gmail.com
Warren Seen
On 01/08/2007, at 12:10 AM, Rafael George wrote:
>
> The comparation between a programming language and a framework is not
> fair, I mean, you said that PHP wants to be where Rails is right now,
> but why don't you compare Rails with Symfony/CakePHP/Zend Framework.
>
Speaking objectively :-) I think even if you look at many of those
frameworks, they're still chasing Rails, in terms of how mature they
are, how consistent they are, and just general mindshare. I'm
honestly not sure I could use something like CakePHP after using
Rails, it's similar enough all right, but it's still PHP and thus a
pale imitation of RoR.
Ruby is a big part of why Rails is the way it is, but at the same
time Rails is driving Ruby adoption, they complement each other
nicely. In contrast, I don't see anyone watching a screencast for
cakePHP or whatever and setting out to learn PHP just so they can use
it.
Ruby was not an obvious choice for writing a web application
framework in, yet a good many of these PHP MVC frameworks have only
sprung up *after* Rails came along. I think it's fair to say that
although its market share dwarfs RoR, PHP and its many MVC frameworks
want to be where Rails is right now, particularly in terms of ease of
use and time to market :-)
Cheers,
Warren
Jose Hurtado
Very good point on Ruby being a fundamental part of Rails.
I remember reading somewhere that David Heinemeier Hansson was a PHP coder and that he actually tried to implement Rails on PHP first, but out of frustration he looked for an alternative language, and then found this new language fully OO language that was ideal for the task: Ruby.
This can not be understated, Ruby makes a lot of the magic in Rails possible. Unless PHP itself becomes more like Ruby, no framework will ever match Rails, PHP Frameworks have a constraint inside that limit's their power, namely PHP itself.
However PHP is very much alive and thriving, PHP 6 is coming, and the current crop of frameworks is fairly decent. Especially Symfony which builds upon PHP 5 and OOP to build a Rails look-a-like.
So in the short term, nothing will touch Ruby on Rails, in the long term though I would not discount PHP, we might be surprised in a few years... but then again RoR is not sitting still either.
I continue to code in PHP 5, but right now I have to admit RoR has no match yet.
Best Regards,
Jose Hurtado
Web Developer
Trumpet Interactive
Toronto, Canada
Warren Seen
This can not be understated, Ruby makes a lot of the magic in Rails possible. Unless PHP itself becomes more like Ruby, no framework will ever match Rails, PHP Frameworks have a constraint inside that limit's their power, namely PHP itself.
However PHP is very much alive and thriving, PHP 6 is coming, and the current crop of frameworks is fairly decent. Especially Symfony which builds upon PHP 5 and OOP to build a Rails look-a-like.
Aurelian Oancea
On 8/1/07, Warren Seen wrote:
>
>
> On 01/08/2007, at 10:47 AM, Jose Hurtado wrote:
>
[...]
> However PHP is very much alive and thriving, PHP 6 is coming, and the
> current crop of frameworks is fairly decent. Especially Symfony which builds
> upon PHP 5 and OOP to build a Rails look-a-like.
Symfony performs model data validation in the controller, so I rather
say that it has a non-intuitive implementation of MVC.
PHP 6 means Unicode and maybe namespaces (or something like that), and
it will be "ready for enterprise" probably in 5 to 7 years from now as
the things are moving now. There is no public schedule and no one
knows when it will be ready.
[...]
>
> The Zend framework *might* be one alternative, but first you need to get a
> big chunk of PHP developers to adopt it - at the moment I would suggest the
> market for PHP frameworks is fragmented, and therefore none of them is
> really emerging as a clear favourite. It seems like the current crop are the
> result of programmers that *want* to be using Rails, but are stuck with PHP.
> I think they're fighting a losing battle myself.
Zend Framework is more a collection of PHP classes (in the same way as
PEAR or ezComponennts) rather than a Web Framework.
The only good thing with it, is that Zend developers started to write
PHP code and they finally can see some of the PHP annoyances.
[...]
>
> Anyway that's just how I see it. Other opinions may vary...
PHP it's cheaper than Ruby, think of hosting, and then you need an
experienced team of developers (anyone thinks that they can code PHP).
> Warren
>
--
Aurelian
Rafael George
I have a question which are the advantajes of using Rails over
Symfony/CakePHP not because they are "copycats", i just wrote an app
with Symfony and one with Rails and i think is most of the same thing,
talking about maintainability and scalability.
Cheers
Raul Murciano
> Ok, guys.
>
> I have a question which are the advantajes of using Rails over
> Symfony/CakePHP not because they are "copycats"
> talking about maintainability and scalability.
...in which case IMHO the comparison would fall on "ruby vs php": I feel
ruby more comfortable over php, with a more natural OOP and some nice
details like code blocks, but If you enjoy coding php and feel more
productive just go on! :)
Greetings,
Raul Murciano
Rafael George
making progress with it and Rails of course, i prefer a lot of things
that Rails have and Symfony dosen't like migrations, but right now i
have some apps written with Symfony, im just thinking which framework
i should use for my next project.
Regards
Brian Hogan
Those are the two reasons I now use Rails for projects... so easy to test and so easy to document. I feel better knowing the app I deploy has test coverage that proves it works as intended.
Rafael George
as in Rails.
Here is a link if you want to know more about it.
http://www.symfony-project.com/book/trunk/15-Unit-and-Functional-Testing