I've seen a lot of discussions revolving around ColdFusion and whether it is inherently a "legacy" language. There are dozens of blog posts proclaiming the death of the language, and every comment seems to share a story about just how "legacy" CF is. Today, I'd like to look closely at why so many dare to call us a legacy language, and what we can do about that.
The Definition
Let me back up and explain what I mean when I say legacy. Wikipedia tells us that legacy code is "source code that relates to a no-longer supported or manufactured operating system or other computer technology." Michael Feathers, in his book Working Effectively with Legacy Code, defines legacy code as code without tests. Ouch.
Personally, I think "legacy" means any application which is aging due to poor structure, poor practices or poor coding. In my mind, any use of cfdiv, cftable, cfform, cfcalendar, or other funky UI-based tags is a big no-no. Many of these are unsupported in Lucee (for good reason), and are difficult to extend, customize or rebuild.
The Naysayers
If you don't mind, allow me to share a few glorious remarks about ColdFusion and legacy practices. Please have some ice water ready. :)
I am collaborating with a company right now that absolutely refuses to leave CF, they've got a lot invested, but I think it says a lot about language when its existence is largely based on and centered around legacy and maintenance instead of innovation and truly making things easier on the developer.
There is a reason why devs are leaving CF.
From "Is ColdFusion Dead?" on Reddit/r/coldfusion
Note the dearth of facts here - this remark has more opinion than a Rotten Tomatoes review, but it seems to be based on something. Take a look at this next quote containing some tangible criticism:
CF applications tend to have been written by newcomers to programming who had no formal training in programming and little experience or knowledge of modern programming. Do not consider a career in maintaining legacy CF applications unless you enjoy maintaining ill-designed spaghetti code.
From "Why learning ColdFusion today is a waste of time"
The reasoning here goes: All CF apps are written poorly. Thus you should never write a CF app.
The Perception
Nevermind that these articles or comments are old - in some cases, over a decade old. Nevermind that they tend to avoid hard facts. The sad reality is that a perception exists, and despite my prevous blog post title, I do care about that perception.
Most naysayers are reacting to what they perceieve of CFML as an "XML language" which intermingles business logic and HTML. If you can find a "moral of the story" in those comments, it is that poor programming practices create legacy applications.
Who knew, right?!
The Legacy
Although it is dumb to blame the faults of the programmers on the language, we do need to recognize that much of that legacy CF still exists. Yes, that "awful" CF code an intern wrote 15 years ago may be running perfectly fine in its original state. That is both awesome and horrific. That should scare us - just because CF can run forever with no maintenance doesn't mean it should.
It's not a secret that we are a minority language. Most agencies or organizations writing CFML at some point seem to fall into bad practices, building their technical debt without even realizing it, and architecting (if that word even applies) monolithic applications with no MVC framework, dependency injection or even version control. This is what developers are rejecting, and they are fair to do so if that is what it means to write CFML. We as a whole, as a community, need to step away from these failings and strive towards Modern CF. (And by "Modern CF" I mean pretty much anything Ortus is doing.)
Many legacy CF apps run for decades with little or no maintainance, further damaging the codebase and making it harder to upgrade the server or CF instance. In other cases well-meaning but inexperienced developers are tasked with learning CFML and maintaining the company's bread-winner CF application... or porting it to another platform entirely.
The Comfort Zone
Too long have we wallowed in our comfort zones, content to produce the same old code with the same old vulnerabilities and the same old flaws. We need to move away from legacy practices and modernize like our lives depend on it. The theme for IntoTheBox 2019 was "Modernize or Die", and it is indeed appropriate. It's time to embrace cfscript, open source, MVC, CI, CD, serverless, and testing.
We have a legacy of legacy, and until we get past that we will never get past that.
I've been incredibly pro-CFML in my last blog posts, and I always will be. Like any language, CF is awesome provided certain (modern) practices are followed. But I'm not stupid - legacy CF apps need serious help.
The Plan
This is a hard road for some. You may be holding the bag after a decade of, ahem less than exemplary work by your peers or predecessors. Man, I don't envy you - but I will help you however I can, and right now that seems to be through my blogging.
Several weeks ago I received a Twitter DM from a fellow (we'll call him Jack) asking if I could put together a few modern CFML code examples. Jack specifically wanted help with modern script and crud functionality, and told me "Even though I’ve been doing this a long time I feel I’m going in the wrong direction with legacy coding ways". He's hoping I can put together a few blog posts, example applications, or anything that will help him and others modernize their CF coding practices.
So today I'm starting a new blog series. I'll be releasing a blog post every month covering Modern CF - starting with cfscript. If you want to influence the topics I'll be covering, go ahead and fill out my Modern CFML survey.
There is light at the end of the tunnel - far more, in fact, than most realize. Still, it will be a long time before that legacy perception of CF goes away - if it ever does.
Thanks for reading, and happy CF-ing!
Top comments (4)
The problem is there are tons of legacy CF apps out there, and tons of developer willing to update them but no buy in from management on why they should spend any money on an app that works perfectly fine.
Yes, yes, and yes. I guess I'm writing to those who have the latitude to make decisions about company tech and development methodology. (Such as the fellow who wrote me.)
What's a good way to encourage buy-in? You'd think security flaws and end-of-support would be enough to push businesses to upgrade...
I think it's time to start talking about the apps that are not legacy CF. The issue with that is they are not very 'public' apps. For example: The CF shops out there that are developing modern apps for businesses, what are they? where are they?
Those 'modern' CF apps need case studies written on them on sites like this.
Speaking of spaghetti code have you looked at a JS app? :)
Amen. A lot of modern CF apps are still closed-source, whether government / public sector or other business apps, so it's harder to get public awareness of stuff.
Ortus does a lot of open source work. I'll try to dig for others - obviously forgebox.io is a good place for open source libraries, but I might reach out for more public case studies.
Lol! I've written some pretty poor jQuery junk back in the day, but JS isn't too bad if you're careful. ;)