To some degree, the responses support the position
June 09 2009 by 
Marc Funaro
I wanted to take a moment this morning to respond to another post, and related comment thread, that I came across yesterday by Michael Dinowitz:
http://www.blogoffusion.com/051709-wrong-coldfusion-religion.cfm
Interesting. This post mirrors my sentiments, as posted by me not more than 3 days later (after not having seen his post at all). This "debate" seems to be getting some attention across the board, and I think that's a very good thing.
The post is (by the author's own admission) a "rant" (surely no more so than my own endless dissertation). The real value, as was the case for my post, comes from the responses.
In those responses, here's what stands out, in my view:
"From a pragmatic viewpoint, my knowledge of and experience with frameworks and OOP is a "value-add", like my certifications, that puts me in the top tier of candidates for jobs and allows me to command a high salary. From a developer viewpoint, every program I've seen (that wasn't written by an expert) that didn't use a framework was a brittle, opaque "ball of mud" that was difficult to understand, modify or enhance. Lots of nested cfincludes, copied and pasted repeated code, and unscoped variables. No thanks."
"The problem comes when that one page grows to 100 and you have to explain refactoring to the client."
"Yeah , I recently was offered a job; the first thing the recruiter told me was it was CF 5 with no upgrade forseen. I politely declined and the recruiter said "yeah thats what everyone says, I'm having a hard time filling this position."
The takeaway I'm getting from these comments is:
1. You cannot command a high salaray or be a real candidate in the CF developer world unless you know OO.
2. No framework + no OOP INHERENTLY = "ball of mud" apps.
3. Non-OOP INHERENTLY means no centralization of business rules. It also inherently means copy/pasting of code, etc.
4. Refactoring -- adjusting the code to match the new reality of the situation -- is just wrong.
5. It is better to turn down a job than have to (learn to) solve problems using non-OO techniques.
I'm sorry (okay... no I'm not), but every single one of these points flawed.
1. If you write good programs and deliver what the clients want, you are going to get paid, and it'll probably be more than what your car mechanic gets per hour. Usually much, much better. Sure, the VERY highest paying jobs probably involve large companies hiring computer-science grads to do programming in OOP style. How many of us CFers are candidates, really? And the real high paying jobs related to OOP are not CF, they are Java, or C++. Trust me... non-OOP CF, you still won't starve, you'll actually be pretty well off. Take care of your clients, and you'll be just fine.
2. This is false. If anything, the high potential for misuse of frameworks and/or OOP in CF is going to add on a nice thick layer of mud... only now, it's from someone else's yard.
3. This is a pantload, pure and simple. A bad programmer will write bad code, OOP or not. The OOP paradigm makes it even easier to write bad code, for many non-CS, ColdFusion developers. Just because you're not using OO does not mean that you cannot logicially construct an application to be maintainable, with centralized code that is not duplicated "everywhere". The very best solution in the ColdFusion world is probably a hybrid scenario, but with an emphasis not on all the OO buzzwords, frameworks, ORMs, etc., but on leveraging what CF does best, and ultra-conservative use of OO only when it becomes clear in the project that it's time to create a class for something.
4. Refactoring is an essential part of good software development. No, one should not be refactoring tons and tons of code all the time -- that means that not enough thought has gone into the development (OOP or not). But neither should we shy away from proper maintenance, and it IS a requirement. Clients should be prepared for this up front -- that as our understanding of what the system is meant to do evolves, so should the code... and that means regular refactoring. Oh, and the "billing by the hour" crack? It's a wash. I'll bet you can spend the same amount of time (and money) with CF, if not more, trying to anticipate every last possibility, to the point of engineering paralysis, than you would spend refactoring code that needs to meet new requirements or a new understanding of the problem domain. One could just as easily argue that in just as many cases, where the choice to use OOP is less cut-and-dried, OOP is the same "billing by the hour" trick, just in advance.
5. Wow. Just... wow. This is what the CF community has come to? THIS is what I think I've been talking about. Here's a client that committed to CF to begin with -- with other, lower-cost, mature options out there at the same time, and now we're turning our back on them just because it's not "The cf that lets us practice our religion." I bet at the end of that search for a developer, they were wishing they'd never chosen CF. Is *THAT* what our goal is? Really??? How elitist... not what this community was about when I joined up, back in CF3.1 days.
I'm starting to wonder if people that make statements that essentially amount to the five takeaway points above (and geez, I still have to reiterate that I DO feel OO and frameworks DO have a place!) are really just bad procedural programmers.
Here's a challenge for you -- try TAKING that CF5 job, just so you can prove to yourself that you can in fact write a clean, non- (so-called) ball-of-mud app that, to top it off, doesn't suffer from framework or object bloat in the extreme. I bet you might find that by developing some conventions for the particular CF5 app, planning it out fairly well, and making intelligent decisions based on what CF5 had to offer, you'd be surprised at what you could accomplish... and probably in the same amount of time.
Or, be an OO purist, and turn down any CF job that doesn't have OO, and make those clients that chose CF feel bad for having done so.
I also have to agree with commentor "TJ Downes". The balance of "time spent" in programming vs. "money spent" in hardware to support the bloat on what should otherwise be a well-performing platform has never been independently documented for any significant number of real-world scenarios. And honestly, cpu, ram, etc. are still not unlimited resources. But nobody's really paying attention to that, are they?
Except the guy that's gotta write the checks, I suppose. :)
Marc
Posted in ColdFusion | OO | 
5 comments
Jun 9, 2009 at 10:50 AM
Marc, presumably in the midst of all this debate, you are continuing to work (i.e., program, do what you said you love). So, from a much less theoretical perspective, what do you find yourself using? Is there a framework you like? Is there a design pattern that you find yourself using frequently?
I think the debate is interesting, but it seems to me to be breaking down to a level that is less than useful. Could it be enhanced by talking more about the ways of writing good non-OO code?
Jun 9, 2009 at 11:09 AM
@Sarah:
I am indeed working -- you wouldn't think so with the amount of time I've spent blogging lately. ;)
I current do not use any broad, monolithic framework. ColdFusion *provides* the framework already.
I shudder to think how others will interpret your "design pattern" question, because it now carries with it so much OO baggage.
But I do agree that the next round of discussions needs to focus on writing good CF code that does not immediately lead into the OO paradigm. (Notice I did NOT say "non-OO".) It is overdue, and it's the next logical step. While I think there's still some value in hearing the broader points of view on the subject in the CF community, I do think the time will come when some "design patterns" of our own, that are not mired in all that OO has brought to CF, will come to light. Better writers and programmers than I am have already started doing so, I'm sure.
I think what's more important is not necessarily to focus on specifically writing "non-OO" CF, but in taking the GOALS of OO, and deriving solutions in CF that meet those goals, using actual objects, and yes, perhaps even frameworks and an ORM, only where absolutely necessary, but not as the starting point for every application.
I guess if I were going to answer your question with any of the specifics you were looking for, I'd say yes, I'm still using what would be considered, I suppose, an MVC architecture. I'm still isolating business logic from presentation. I'm constantly making sure that I'm not repeating myself, and if something really just feels wrong, not to ignore the feeling, even if it means some "refactoring" (yet another buzzword that carries too much paradigm-speak along with it now). And, I'm being as diligent as a one-man shop can be about documentation... which makes any app much easier to understand, regardless of style. Documentation doesn't come just from the up-front design... it's a work in progress as the app evolves, and without it, it's just like the code rot that happens when people are afraid to "refactor".
I agree... this whole conversation will be greatly enhanced when we start talking about the alternatives, and that's what I'm hoping will come to pass.
Jun 9, 2009 at 12:06 PM
Marc, I don't see any reason that MVC is inherently OO. Maybe some view it that way more easily/naturally. For me, having learned procedural programming first, nothing OO comes easily/naturally yet. I'm not tossing OO, simply choosing to do what comes more naturally at this point.
I'd like to see any examples that you might be willing to share demonstrating how you use MVC . Actual working code would be great, but alternatively, a description of how you set up your files to handle the various tasks would be informative too.
I hope people will respond to your comments about "our own design patterns" not in the theoretical sense of the OO v. non-OO debate, but in a more practical sense.
I'm so interested in the topics because I'm at the point where I probably need to refactor a piece of code. Luckily, it's small enough that it shouldn't be too painful, but I'm sorta in that state where you were when you weren't accomplishing much because you were trying to figure out how to do things in OO. I need to refactor so that as the code grows, it will be easier to manage, but I can't decide what I'm refactoring to!
Jun 9, 2009 at 2:41 PM
@Marc: I think picking and choosing certain statements from the comments and then portraying them as views shared by the majority of the community is more than a little bit of a stretch.
I sympathized with your original rant against OO because I understood the need for you to assert the value of your own, non-OO coding methodology in what you perceived to be an increasingly OO-centric ColdFusion-world.
But if you want to take the energy generated by that post and turn it into a constructive discussion on design patterns and practices that can be applied regardless of whether one is coding in OOP or procedural programming, you'd be better off not making such broad assumptions about the mindset of the community at large and then calling the community to task over them. That's a sure way to make it an argument rather than a discussion.
@Sarah: You're right, MVC is not inherently an OO approach to coding. It's even possible to do MVC without a framework, although anytime you have a controller aspect to your application that routes the action from one piece of code to another, I'd argue you've pretty much ended up creating a de-facto framework.
Jun 12, 2009 at 9:07 PM
For the most part I agree with all the points you've made here. My ideas are as follows.
1. I have no idea what "ColdFusion" jobs pay since I haven't really looked in a while. Gathering such a survey would probably prove to be complicated as there are so many variables involved in the equation. Be that as it may, I think you touch on a very important point here: the money aspect. At the end of the day it all boils down to whether or not you make your clients happy and you get paid for it. How you get from point A to point B is purely up to you, especially if you are a one-man shop. That's the beauty of the flexibility that CF provides. Whether using OOP increases productivity for you or not, you should ultimately do what works best for you. Adding OOP to one's skill set for the sake of job security and/or increased pay is always going to be a personal decision based on the demands of the current job market. Maybe the day will arrive where all CF jobs will require knowledge in OOP. Maybe it won't. For the time being, I say as long as your code works, performs well under load, and is maintainable, there's not much more you can ask for.
2. I've yet to use a framework myself. I do know what they're about and how they work. I just haven't gotten around to fully embracing a particular one. Furthermore, while I do use beans, DAOs, and gateways, I would call the programming I currently do far from what some may be consider to be "true" OOP. For the moment, I use CF where it works best: custom tags to control my layout, Application.cfc to control application behavior, CFCs to contain my business logic, and much, much more. I'm continually learning about the language's many intricate features. There are pages on my organization's site that produce a significant amount of content with only 4 lines of code on the calling page. No framework. No OOP. I definitely wouldn't call 4 lines of code a "ball of mud." It's all about your strategy and how you make the best use of the language.
3. Non-OOP shouldn't necessarily mean non-CFC. It makes total sense to group together a collection of related functions into a CFC, even if that CFC will never be turned into object variable using either CreateObject() or CFObject. The principles of code reuse and organization can still be applied. That's what CFCs were originally made for. I actually kind of miss using CFInvoke to call a method without having to run an init() function first.
4. It's a given that almost any app will need to be maintained or eventually refactored, regardless of how it was built. Part of doing it right the first time is making that work easier for whoever gets to work on it in the future. I think the original comment of "when that one page grows to 100" doesn't really pose a concrete problem scenario. A requirement like that should have already been considered in the design phase. Plus, expansion of a site should be trivial if the new pages are just containers for HTML. It all depends on what those "100" pages are expected to do.
5. I noticed in one of the comments that someone did take up a job doing CF 5, so I don't think the current state of affairs is nearly as bad as it could be. Sure, there will be some that will turn and run from such a job for the sake of maintaining their sanity. I once talked to a CF expert who said he turns down all jobs that have anything to do with refactoring procedural code. To each their own I guess. I respect that. What's more important to me is keeping the bread on the table. Or in my case, the ramen noodles and cheese crackers.