You are here: Home » Innovation » Running into Rails: Why We’re Breaking Up With ColdFusion (Part 1)

Running into Rails: Why We’re Breaking Up With ColdFusion (Part 1)

Posted by Jon Shearer | Published on August 20, 2012

Recently our team made a big decision, one that we’ve spent quite a bit of time considering and researching. We’ve decided to switch from ColdFusion to Ruby on Rails, running on top of a Java services layer.

Where we’ve been

For 12 years now, we’ve been primarily a ColdFusion development shop. Starting out, our framework of choice was Fusebox. For the last eight years, we’ve built apps using Mach-II and have contributed to the Mach-II open-source project in recent years.

For a while we even developed several Flex apps, and we had our fair share of Flash development and a few Director (Lingo) apps back in the day.

We’ve been supporters of the ColdFusion community, hosted Ben Forta and other product evangelists, and have participated in Adobe-focused user groups and conferences.

Our team consists of former .NET, Java, classic ASP, C++, Ruby and PHP developers that have all come to appreciate ColdFusion for its ease of use and rapid application development.

Powered by ColdFusion, daveramsey.com has risen to an Alexa-rated top 3,000 website (U.S.) and served millions of visitors. We’ve built business tools, web-based apps and subscription websites. We’ve even survived traffic spikes from The Oprah Winfrey Show, 60 Minutes and Larry King Live.

So why is a shop that’s been a long-time ColdFusion advocate looking at switching now?

Why we started looking

Over the last several years, it seems as though innovation for the ColdFusion product has slowed. Granted, it’s a language that’s had second-class citizen status for years more. PHP, Ruby, Java and Python all enjoy higher acclaim.

While we’ve been able to leverage ColdFusion to do many things, it has continued to fall short in a few key areas—decent debugging for example.

To top it all off, there aren’t a lot of senior developers jumping at the chance to learn ColdFusion as their language of choice these days, making it harder to fill our current openings.

So we decided it was time to re-evaluate our future with ColdFusion.

Find out what we were looking for that ColdFusion didn’t offer in the next post, Running into Rails: What We Went Looking For (Part 2).

Be Sociable, Share!

Posted in Innovation | Tagged ColdFusion, Innovation, Ruby

snake

No d e c e n t d e b u g g i n g? Y o u r j o k i n g, c f h a s m u c h d e b u g g i n g t h a n m o s t.

Jon Shearer

Not joking. CF does have some debugging functionality. We’ve not had great success with it and has been quite brittle. I’ll leave that there and let Doug reply in more detail.
EvilDarthMaul

CF lacks the same level of debugging that you can achieve in some other web programming languages like ASP.NET. It’s simply not possible to step through CFML code, pause execution, change values on the fly and resume execution. This alone it’s huge! Dumping, aborting can only take you so far.

http://coldfusionbeyond.com S. Wilson

As a long-time CF developer, it saddens me to read this post after reading the post from 2010 from Doug and his going from having a low view of CF to extolling its virtues. I’ll be curious to see what you felt Ruby offers that ColdFusion can’t do, as I’ve found there is very little, if anything, ColdFusion can’t do that other web application languages can.

I am surprised to find complaints about the debugging considering the huge wealth of debugging information available natively in ColdFusion. I always thought the DR team would mostly be comprised of native CF developers with a few converts, so surprised that it seems like its the other way around?

I’ve seen plenty of senior level ColdFusion developers out there open to opportunities. I wonder if they just didn’t see the posting (I can only recall one I saw in the last year or two – I never saw the many postings that I noticed while browsing the Join Our Team page).

Of course I wish you guys the greatest success in your endeavors, even if it is turning from ColdFusion to Ruby.

Jon Shearer

We’ve had an extremely difficult time finding developers of high caliber that are either programming in ColdFusion or want to. I’m sure there are great developers out there who are open to opportunities, and perhaps they haven’t seen our posting. While that may be true, we have 12 roles we need to fill today and most ColdFusion or PHP candidates currently applying are junior to mid-level at best for what we need.

For the last several years, most of the developers we’ve hired have transitioned from other languages to ColdFusion to work here. Doug was one of those. There have been very few senior ColdFusion developer candidates. We’ve experienced what seems to be a shortage in the market.

On another note, I’m aware of two other senior developers who are influential in the ColdFusion community that are also looking to move off of ColdFusion. We’ve spoken with one of them about how we made the decision and our process in getting there. Their organization is taking similar paths to move to another language.

All that said, I’m not trying to convince die-hard CFers to leave what they love. We’re simply sharing our viewpoint and where we’re headed. ColdFusion is just not working for us anymore. If it is for you, stick with it.

http://andymatthews.net/resume.html Andy Matthews

No offense Jon but saying that you can’t find talented CF developers is a copout.

ColdFusion is so easy to learn why even bother looking for a “CF Developer”? Just find someone that’s got skills and teach them CF in a week. They’ll bring a raft of other abilities to the table and you find someone who doesn’t “need” CF to be productive.

That said I’m sad to say that I agree with other parts of your rationale. Adobe doesn’t seem to love ColdFusion any more. It’s always been fringe but the decisions that they’re making in the last 2 years regarding other products make ColdFusion’s future seem quite uncertain.

I wish they’d open source CF like they’re done with Flex. Then the rest of the internet would have to shut their mouth’s about ColdFusion.

http://daveramsey.com Jon Shearer

Actually, we’ve not tried to hire ColdFusion developers for years. Our postings have focused on finding good programmers. The thing that has hindered us is they see the line at the end of the post “** If you are not already, you must be willing to commit to becoming an accomplished ColdFusion programmer within the first 60 days. **” The vast majority of team members we’ve hired had little to no experience with ColdFusion. What hinders us is those who don’t even give us a chance as soon as they see we’re a ColdFusion shop. Like it or not, ColdFusion has second class citizen status. We could try to change the perception that’s been there for years. It might be worth it if we felt the product was leading innovation. Where we landed is that ColdFusion is not growing with us. Hiring is just one aspect of the pain that caused us to start looking for what may be next for us.

Doug Smith

@S. Wilson: My post did highlight things that I did (and still do) appreciate about ColdFusion, though I didn’t really extol its virtues. I was primarily trying to educate other Java and Ruby developers who might look down their noses and imply that ColdFusion was not a “real” language or had died long ago.

I think ColdFusion’s lack of innovation was a much bigger factor than the weak debugging functionality. Granted, there are ways to make line debugging work, but our team has found them brittle and inconsistent to the point of being unusable in our real world. Debugging in Ruby is better, though it isn’t Ruby’s biggest selling point either. It’s much more about the innovative Ruby and Rails communities who have arguably been leading the way in improving web development technologies for many years.

With my previous Ruby/Rails experience I am thrilled by the improved productivity and innovation we will experience. I do remain grateful for the work we have been able to accomplish in ColdFusion, as it has enabled us to help millions of people and come the place where we can be even more influential in the future.

http://www.boyzoid.com Scott Stroz

I hate to say this, but if you could not get step debugging working….you were doing it wrong.

Matt

Debugging is one of ColdFusion’s best features, you must be mistaken.
http://www.bytestopshere.com Sami Hoda

Decent debugging? Please explain.
MNDeveloper

I look forward to part 2 on why RoR has been selected. ColdFusion has been on its way out for some time. As with any technology, there are pros and cons associated regardless of the language, framework and tool set. From what I have seen in the past, we typically gravitate towards familiarity.

Jon Shearer

It was a hard choice for us as we have quite a bit invested in ColdFusion and our entire development team has been working in it for some time now. We’re extremely familiar with the language and have been able to do a lot of really cool things with ColdFusion. Transitioning to any other language is a big undertaking and costly. We have developers with backgrounds in Java, PHP, Ruby, .Net and C++.

I’ll explain more how we landed on Ruby in Part 2 & 3 of this post.

I’m interested in your comment “ColdFusion has been on its way out for some time.” Why do you think that is?

http://www.linkedin.com/in/zackpitts Zack Pitts

I agree CF has been on its way out for some time. Here’s why:

CF has been late to every party that developers like to attend: OOP, script syntax, ORM, and open source options. When those features have finally been released, developers have had to suffer with a clunky or incomplete implementation that requires workarounds or additional frameworks to compensate. Those that do stick with it and work with the latest/greatest features have a horrendous time finding third-party hosting that compares with PHP options/prices. Their only choice many times is to go the more expensive VPS route. Many devs eager to use the new features in their jobs have had to wait until their department’s budget could afford the upgrade.

Because of these hurdles, many, many good developers over the years have felt alienated/limited and have long since left CF because of it. When high quality devs leave, what’s left in the talent pool? A glut of five-taggers who are holding onto their jobs for dear life in government and other large corporations that are still beholden to CF (pockets of AT&T, Boeing, and the like).

On the other side of this, organizations are having a harder time justifying the sheer cost of CF. Many already have high software costs wrapped up in Windows and SQL Server. Adding CF on top of that is just stupid when ASP.NET comes “free” and built-in. And those who are running on Linux with Apache and MySQL are scratching their heads trying to figure out why they are paying $8k for an additional server technology when they can just use PHP. And no cash-strapped tech startup trying to get their product to market is going to invest in a CF server farm.

Compounding the problem for organizations already running CF is the ever-shrinking talent pool. They are forced to recruit straight out of college, proselytize devs from other languages or win back former CFers. When you find yourself trying to convince a candidate to convert to a particular language that is largely perceived in the industry as a dead-end… DANGER! DANGER, Will Robinson!

All things considered, it’s pretty hard to run a business that is dependent on any flavor of CFML. And that’s why it has become largely a legacy technology that is on most IT organization’s sunset list.
MNDeveloper

Below (or here–> http://www.indeed.com/jobtrends?q=cold+fusion&l=&relative=1) is one measurement of the ‘state of ColdFusion’; 2009 may have been the peak. It is by no means the end all or final measurement of the languages relativity; it is simply a single metric that can be used to begin measuring the state of a language according to how many companies are paying people to be proficient in it.

The languages you have listed are very much first class and, to be honest, all of them can be the ‘right tool for the job’ considering the abundance of corresponding frameworks and libraries available today (most of which are even open source). The cost of supporting multiple languages across the organization will become higher than supporting a standardized language most of the time for obvious reasons. Choosing the right path now will help reduce costs and the risk associated with more moving parts later on. For example, initially I thought it would be ideal to have two distinct languages (Flex/AS3 and Java), one for the server side and another for client (UI) code. However, over time small nuances crept into the scene and grew more aggravating with each new line of code added. Some of these were:
1) Two sets of data objects needed to be implemented/maintained in each language for the models to support serialization.
2) Trying to find good developers with proficiencies in both languages was difficult; trying to find two good developers each proficient in either language was challenging.
3) Build tools (Flex Builder, Eclipse & Maven), although worked, would consistently be quirky during heavy commits among other developers.
Given this, we have decided to go all Java and swap out our client side (Flex/AS3) code base with the GWT framework; it will take some time, but, that is the goal. Most good developers I have worked with in the past are eager to write server side and client side code. In fact, switching between the two keeps them engaged and keeps them challenged. Learning a library

cold fusion Job Trends
Cold Fusion jobs
http://www.boyzoid.com Scott Stroz

Did you guys looks at Groovy/Grails?

Jon Shearer

We did. Check out Part 2 here: http://www.developwithpurpose.com/running-into-rails-what-we-went-looking-for/

Travis

I always thought you choose your tool depending on your problem. Being a dedicated CF, .NET, RoR, etc shop only makes sense if you have the expertise in that area. If you can’t find advanced CF programmers, that’s one thing, but the majority of your post sounds like CF isn’t cool enough for you any more and you’re just looking for an out. I know you guys are pretty high speed/low drag, but maybe focus on being a technical solutions provider using the appropriate tools instead of a cool kid shop. I’m not advocating you stay with CF or that you shouldn’t use RoR, I’m just saying there isn’t much point in being overly dramatic about it either way and cornering yourself into a single solution because “we’re a ____ shop” doesn’t make any sense. On a side note, if indeed.com is any indication of the size of the ruby community, it isn’t much bigger than CF.

http://daveramsey.com Jon Shearer

Travis, I completely agree that choosing the right tool for the problem is crucial.  It’s not about what’s cool or not, it comes down to what works for the needs of an organization.

The key is defining the problem.

For some problems, choosing a language that does one thing (or several) really well that a particular project could benefit from could be right on.  There’s strength with this approach, especially for freelancers or start and stop projects.

Another approach could be to let each team within the company pick a language that works for them. That could improve their productivity especially if the majority of that team has more familiarity with the language. They can move faster and get more done with less. Especially if they enjoy that language.

A third reason may be that a team wants to learn something new and be challenged.  Trying out a new language might be a way to feed that need and keep them engaged (i.e. retention). Let’s face it, most of us enjoy programming for the challenge of learning new things and solving problems through that process.  If we don’t get that in our current role/company/technology, we may start looking for other places where we feed that. Granted there are other ways to stay challenged. I present this because I’ve seen other shops take this approach, whether I agree with it or not.

There are other approaches, all or which have their strengths and weaknesses.

I would suggest that picking that the right tool in any of these situations may be less about which tool is “right” for each project or team and more about what “works” for a technology team holistically in their environment.

So on to defining our problem.

For our company, we have a few key challenges that are big factors in sticking with a core set of languages.

1. We support 15+ business units with various web apps. We also support the company as a whole. We want to leverage the work we’re doing for each of them across the organization while avoiding the big “code stink” of not focusing on reuse. By focusing on a few select languages we also benefit from sharing our skills, learning, tooling and methodologies. If we write apps in too many languages, we shoot ourselves in the foot here and end up spending more overall. This is true for us regardless of the languages we chose.

2. Risk management. Focusing on select languages allows us to backfill and support different business regardless of internal team member movement and exits from the company more seamlessly without having to hire for a specific skill set, or ramp someone up in a language they’re unfamiliar with. This increases our ability to respond to and partner with the business in the gap.

3. Attracting the talent we want. Let’s face it, there is a “cool” factor at play here. Google, Facebook and other “cool” companies attract talent because that’s attractive to technology professionals serious about their craft. They want to learn, grow and try new things.  Our experience has been that ColdFusion as a technology doesn’t attract (rather it repels) entrepreneurial minded technologists.  To continue to partner with the business as it grows, we have to grow our team with like minded individuals. It’s worth broadcasting what our team is doing to attract strong players that are interested in the same things we are.

4. Ability to move fast. ColdFusion is good here. It’s served us well, but we felt it was time to look at what was out there that might be able to fit the bill better. Productivity was a huge reason we chose Ruby on Rails.

5. Innovation. To support a growing business, we have to constantly look at what we need to do to grow with it. We want to invest to a toolset that is on the front of the bell curve and not on the trailing end.

In the end, A combo of Ruby on Rails and Java was where we landed.  It works for us and our needs moving forward.  It may not be a good fit for everyone’s defined problem. We’re not advocating that it is.  It is however, part of the solution for us.

The focus of this post (and the other two to follow) is not to convince everyone else that the path we’ve chosen is the right way. Or that ColdFusion debugging was our key reason for looking at other languages. It’s simply an example of one thing (albeit not the chief reason or even strongest, so perhaps a poor choice to include in this post). Each shop has its own challenges.  We’re just sharing where we are and how we got there. We spoke to several other shops that shifted from a focus on one language set to another and it was extremely helpful for us.

Our hope is that sharing this is helpful for others considering the same.

http://www.linkedin.com/in/zackpitts Zack Pitts

Let’s see…

- Difficulty finding qualified senior CFers willing to move to Nashville
- Enterprise server licenses are $8k a pop
- Server performance drastically decreases as OOP increases
- Language has stagnated
- No sign of Adobe increasing market share
- No sign of piquing interest of new developers

As a long-term business strategy, it’s a no-brainer to CFDUMP it.
http://erniemiller.org Ernie Miller

A friend just told me that you guys were making the leap to Rails. As someone who greatly respects the FPU mission, let me be one of the first from the Rails camp to say: welcome aboard!

http://daveramsey.com Jon Shearer

Thanks Ernie! We took a lot of time to make the decision. We believe that Rails + Java is the core combo that we can grow with moving forward!

BTW – we’re hiring – interested??

http://erniemiller.org Ernie Miller

Hey Jon,

Thanks for the interest, but I’m pretty happy here at LivingSocial.

Corey

Having done CF for awhile back in the day, I am not a huge fan. I think it just really never changed with the times. Good luck with your Rails transition! It was the right choice.

http://daveramsey.com Jon Shearer

Thanks Corey! We’re excited about it!!

http://cfmumbojumbo.com Tim Cunningham

Wishing you the best in your journey. As a VP of a ColdFusion shop with 80 developers, I understand the pain of finding new developers. We just create our own ColdFusion developers and keep our senior developers happy. It is not that hard. If a person can program another language well they can program ColdFusion extremely well in a short period of time.

It will be interesting to see how many “senior” Rails developers you can find, from what I have seen senior tech talent is hard to come by in all languages.

I don’t disagree that Adobe has some catch up to do, and believe me they know it. From what I hear they are committed to releasing more often and making things more modular. In this day and age one can not simply release every two years and stay relevant.

Best of luck to you guys, I met some of your crew at Adobe Max a couple years ago, they even gave me a Dave Ramsey “The Total Money Makeover” book which is sitting on the shelf across from me now. Your team members I met seemed very knowledgeable and personable, I hope the only CF guys are still gainfully employed?
http://www.boyzoid.com Scott Stroz

Jon and/or Doug – would you guys be willing to come on the CFHour Podcast to talk about your decision, maybe give some more details as to why the swich and how you guys decided on Ruby?

If you can’t get my email form the comment submission, you can reach me at scott [ at ] cfhour [dot ] com.

Thanx!

Jon Shearer

Sure! We’d be happy to share the process we went through and why we landed where we did.

http://www.henke.ws Mike Henke

Decent Debugging? FusionDebug is amazing line debugger. I can’t live without it. Please explain.
Leon Oosterwijk

I haven’t been a web developer for almost 5 years now so I probably don’t have any room to talk, but it seems to me that in your solution architecture CF, or whatever replaces it will become less important over time. Javacript development, and the frameworks surrounding it will drive most of the UI interactions. If you build your back-end services using Java , the RoR(/CF) component will just be the glue. Of course it makes sense to dump CF, it made sense about 7 years ago, but Joel spolsky was right when he talked about spurious rewrites being unhealthy.

I suppose that is the sticking point of all this. Untangling from 12 years of CF investment will be tricky.

Good luck, I’m sure you’ll figure out something good.
Gerardo

I wish you the best with the transition, moving to another development platform is never easy, specially after working for so many years under Cold Fusion.nnCan’t wait to see the new improvements or new applications developed under Ruby, please keep us updated with the transition, I am sure will be fun.
http://twitter.com/BrettBaggott Brett Baggott

I noticed that .NET wasn’t ever even a consideration. I’m curious why. I’m not suggesting it should have been a consideration because it seems like your strength and background is primarily in the Unix world but I’m just curious if there were even discussions about it. In other words, I’d like to know your thoughts on the “.NET world”. Especially considering the strong push of ASP.NET MVC and the innovations at MS surrounding that (i.e. open sourcing MVC, accepting pull requests, adopting hg and git support on CodePlex).
Nathan Stanford

Just so you understand the problem may not be ColdFusion but the fact that some of us are unwilling to move to your location. u00a0I would LOVE to be there as I am a Dave Ramsey Fan but my wife loves living near her family as do I. u00a0I like Ruby on Rails but not sure there is any languaage you can move to and always have developers in your area. u00a0If I was in your shoes I would not have posted the move as you will get plenty of people letting you know there is plenty of debugging. u00a0I would choose to do what you think is best if you can get plenty of developers in the language in your area. u00a0However ColdFusion is easy and you could teach new developers in your area so that you can make sure to have plenty of them available. u00a0This happens in every language.
rmash

I’ve never seen so many clueless CF’ers in my life. We moved from RoR to Coldfusion. Haven’t you ever heard of CFWheels? It is ROR for CF. Sweet MVC. You’re still not using Railo 4 (Blazing Fast)nnThe new school of CF is fresh, get on board!nnGET A CLUE PEOPLE !!!!!
Dillon Hafer

puts “Awesome!” if DaveRamsey.using? :ruby
arthur

this is a testnDid you look at Erlang or MUMPS ?