Originally posted as a comment on Nick Kwiatkowski's blog, this is a revised and expanded version of my thoughts on the "2012 State of the (CFML) Platform". The background to this post can be found in the following two blog posts:
- Judith Dinowitz reporting on the "2012 State of the Platform" panel
- Nick Kwiatkowski's reponse to Judith's post
First off, let me say that I admire the positive attitude behind the State of the Platform panel (and also behind Learn CF In A Week). It's good to see community efforts that are forward looking, trying to improve the perception of CFML and trying to make it easier to onboard new developers. The panel discussion led to consensus that CFML would be helped by several community-driven open source software packages, either commonly used applications or wrappers around commonly used APIs. It's good to see recognition that we need (a lot of) improvement in certain areas.
Nick mentions the traditional "technology lifecycle" in his post and asserts CFML is in the decline / decay phase. I'd hope that is not a controversial assertion - I'd be shocked if anyone really believed that CFML hasn't yet passed its prime? Perhaps you believe CFML is merely "mature" and hasn't yet started its decline but I'd say that is very rose-tinted and denies the facts of a declining job market and the trend we are seeing of companies migrating off CFML to other technologies.
CFML's place in the technology cycle is not something to be all "doom'n'gloom" about. It's just a fact of life and all technologies go thru this phase. COBOL, for example, has been in that phase for a very long time and there are still COBOL jobs advertised and there are still companies running their business on COBOL. But, being realistic, there are very, very few new developers who think "Yeah, I'll learn COBOL and build my career on it!" and overall there are fewer and fewer developers who are actively doing COBOL development these days.
I think it's important that someone called out the panel and follow-up post as being unrealistic. CFML developers have a tendency to a "ghetto mentality" and often lack broad exposure to other communities. That in turn means there's a lot of hiding heads in the sand and insisting everything is fine and CFML is alive and well. Over the years, there have been countless blog posts and magazine articles either claiming that CFML is "dying" or else responding to such claims, staunchly defending CFML. Let's be realistic: the CFML market is not growing, new developers are not choosing CFML over other technologies, companies are not choosing off-the-shelf solutions built with CFML (Mura is a notable exception but it is very much an outlier). Lots of words have been written about why this is the case and such discussions are often full of suggestions about how to "fix" these problems. We're talking about a technology cycle here. The natural way of things. This really isn't something you can "fix".
What you do need to do is figure out how you're going to adapt to a smaller job market and to companies migrating to other technologies. What are YOU going to do about your career?
LearnCFInAWeek is a very slick-looking community project and I applaud the team of volunteers that have worked so hard on it. As I said in my comment on Nick's blog, I think it's too little too late and I wish we'd had it five or six years ago before the decline really took hold. It would have been a great resource when developers still might have been persuaded to use CFML instead of Ruby / Python / PHP / .NET / Java / whatever. It is unfortunate that the very first page is a twenty four step process that requires an account with a corporation to even get started. Compare the process to what it takes with any of those other languages - heck, even compare it with the Railo Express process! - and you'll see that CFML is off to a bad start. Most developers will look at that first page and think "You're kidding?!? I have to go thru all that just to try CFML?" and we've already lost them. Frankly, getting Clojure up and running on Windows is a ton easier - and Windows is very much the red-headed stepchild of the Clojure world. If you want new developers to try CFML, it should be a simple download that you optionally unpack and then just double-click. And it shouldn't require a login. And it should be easy to find on the vendor's home page (ahem, Adobe!).
I interact with a lot of non-CFML developers all the time. Just this weekend I got the "ColdFusion? Seriously?" question again. To the vast majority of developers out there, ColdFusion is irrelevant. Most of them haven't even heard of it. Those that have view it as an old-fashioned, commercial product, and are usually surprised anyone is still using it. Even the most informed non-CFML developer won't have heard of Railo (let alone Open BlueDragon). Yes, it's wonderful that we have a free, open source option these days but it's a tiny drop in the ocean as far as the larger developer world is concerned. It really doesn't matter how many new developers Railo brings into the fold, it's going to be insignificant compared to what used to be the ColdFusion developer base at the peak - which was probably four or five years ago, before Railo even went open source. I like Railo. I use it in production. I've used Railo exclusively for over three years - and ColdFusion 10 is the first version of the commercial product that I haven't even downloaded, since I was first exposed to ColdFusion in 2001. At work we're on Railo 3.3.4. We probably won't upgrade. Sure, Railo 4 has closures which I'd like to use - but we're already using Clojure which, like most of those other languages I mentioned above, has had closures since day one. Sure it brings command line execution of CFML - very cool - but we're already using Clojure for those sorts of scripts (precisely because we couldn't use CFML for that!). Like many other companies out there, we've found CFML wanting in several areas and we've started to incorporate other technologies alongside CFML that don't have those deficiencies. And, like many companies in that position, upgrading CFML - even the free, open source version - is just becoming less and less attractive. Other languages are easier to use and/or more advanced and/or have a much larger developer pool to recruit from and/or any number of other benefits over CFML. The much vaunted advantage of being the more rapid way to build web applications has evaporated: that's a commodity now. CFML - even in the free, open source versions - is an old-fashioned language that competes in a very aggressive space against other languages that have evolved much, much faster.
I'll ask again: what are YOU going to do about your career?
Are you going to remain a "CFML Developer", defined by your language? Are you even able to compete in the current jobs market? I've said repeatedly that lessons you learn from other languages will make you a better programmer - and make you more employable. That's where CFML developers need to expend effort: raising their game. I've been interviewing a lot of people recently for roles at World Singles. The general lack of experience with modern software development processes is holding CFML developers back: TDD (heck, even basic unit testing), automation (of testing and of deployment, CI, CD), source code control systems (learn Git people!), polyglot development experience, understanding the JEE / JVM stack, Agile techniques (Scrum, Lean, Kanban...). The list goes on. I've been saying for years that this is what will kill CFML and, as Nick notes in his blog post, we've seen a lot of the top CFML developers, evangelists and cheerleaders moving to other technology communities where these development processes are commonplace.
Whilst it's all "too late" for CFML in my opinion, there's still a chance for CFML developers to change their game, to learn those new skills, and to find interesting work with technologies that are still in the growth stage.
Don't let your language define you, let your skills define you.