I have been able to carve out a nice niche for myself as a freelance .NET developer. A couple of months ago I decided to stop actively pursuing .NET gigs to focus on Rails. Several of my existing .NET clients have learned of this through the grapevine and have contacted me to discuss. I have assured them that I will honor all my .NET support contracts and will not abandon them if they ever need support, even after the life of contract. There are several topics that come up during these talks that I'm hoping the group will have some advice on how to answer.
- 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.comcomes 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?
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.
Michael Breen wrote: > 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?
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 ;-)
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).
> 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.
>> 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
>>> 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.
> . 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. ;-)
>> . 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.
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? :)
Warren Seen wrote: > 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.
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!
