I’ve been so busy with my house build and learning all about construction techniques for Southwest architecture that I haven’t written anything about software in quite some time. Funny enough though, I have managed to stay busy part time doing some software consulting projects. A big chunk of the consulting work I’ve done in the last several years has been focused on re-factoring old CFML applications into Framework One (FW/1), so I thought I would share some of my experiences and knowledge about how to approach re-factoring CFML applications into FW/1. Even if you don’t work in CFML or FW/1, you can apply the lessons from this post in other re-factoring projects.

Background

CFML has been around as a programming language for the Web for almost thirty years. As one of the early scripting languages for the Web, CFML claimed a significant share of web application development early in its development. Many of those early applications are still in active use on the Web. As a result, there are a huge number of aging CFML applications that are showing their age as time goes on. As these applications age, it becomes more difficult and complicated to maintain and extend these applications to meet the current needs of their users. Common issues I have seen with these aging applications over the last several years include significant amounts of cruft, copy pasta, and technical debt in the form of commented but unresolved hacks in code.

Notwitstanding these problems, which are very common, the main issue I have seen in applications over twenty years old is the lack of a unified development framework. Generally, this lack of a development framework leads to many well known problems including lack of separation of concerns, poor readability, and difficulty understanding program flow.

If you haven’t been working on Web applications for at least twenty years, you may not realize that in the early days of Web programming, frameworks for Web languages were in their infancy and most applications didn’t use them. Over time, programmers built frameworks to make their own lives easier, but early on, there were simply not many options for building Web applications in a well structured way.

But Wait, Why are We Re-factoring?

Owners of these aging applications face a daunting challenge in bringing them up to date, and the single biggest decision they have to make is whether to attempt a re-factoring project or simply give up on the existing application and re-write the application from scratch. If you have never read Joel Spolsky’s blog, you would do well to read his post on the folly of re-writing from scratch. Personally, I don’t draw such a stark line on never re-writing from scratch, but I agree with Joel that you need a very compelling reason to re-write versus re-factor.

The chief reason to re-write from scratch is to migrate your application to a new platform and/or programming language. You might do that because your existing application is written in an “outdated” programming language, but given that there are still mission-critical applications written in COBOL that are still running today, I don’t believe that is a sufficient reason to risk a re-write.

So why might you risk a re-write? The only really valid reason I can think of is to migrate to a new language or platform that gives you capabilities the existing language or platform does not have. In the case of CFML applications, if you are looking to grow your application to “Internet scale” ( i.e. Netflix, Facebook, Twitter, etc. ), you should probably convert from CFML to something else. Streamlining and unifying a codebase built in multiple languages into a single language might be another reason, though at Internet scale I find that less compelling because you will always need a significant engineering team to keep everything running, so hiring a few extra programmers to tackle challenges in specific languages is not an undue burden.

eBay famously re-wrote its application in Node.js. Facebook over time has ported a lot of its code from PHP to Hack, a language of its own design. Can it work? Sure, and those are good cases where the organizations had to migrate to something else and did so successfully. However, unless your organization has a comparable amount of engineering talent available to you, you need to think seriously about your ability to execute on a re-write project. For the vast majority of applications - those not at Internet scale - re-factoring is simply a far more realistic prospect than re-writing.

Frameworks to the Rescue

A word about the proliferation of frameworks. In the CFML world, many frameworks have come and gone over the last twenty-five years. Two of those - Framework One and Coldbox - have emerged as mature, stable frameworks that have been adopted around the industry. There are still other frameworks out there, but for the sake of brevity, I am leaving them out. I have worked with Coldbox several times since its inception, but my last few projects have focused on FW/1, so this series will focus on re-factoring into FW/1. FW/1 and Coldbox have a lot in common, and you can take these lessons and apply them to Coldbox if that is your target framework.

Modern frameworks provide a means to organize application code in a logical and predictable way, a clear separation of concerns, and hooks to systems that simplify development using techniques like dependency injection and aspect oriented programming. FW/1 does these things while doing its best to stay out of the way.

Next Steps

In the next post, I will go into detail about how you can approach re-factoring a CFML application in FW/1 and provide a roadmap and some concrete examples for a re-factoring project.