Yeah, it's long... but some people really need to hear this. Besides, compared to all the tons of (mis)information about ColdFusion and OO on the web, this is a relatively small bit of blog-based sanity.
"There comes a time in the history of every project when it becomes necessary to shoot the engineers and begin production."
I don't recall where it came from, but this faded, worn 3x5 index card, printed in Bold Times Roman, has been hanging in various places in my office literally for years. I've had it since at least 1997, when I ventured full-time into my sole proprietorship. It followed me from my apartment north of town, to my new home south of town. I always understood what it was trying to say, yet only now, in May of 2009, would I discover just how important those 21 words would become to me. But let's get a little back-story in here...
I graduated with a degree in music in 1992. I ended up in the world of technology (even back then, the recording studios had some cool computer-based stuff going on!) I was hired around 1996 to be the IT person for a small company with national and international interests and assets. In addition to getting the office network/workstations up and running, I was given the opportunity to develop a regular website (plain old HTML, which I had done for a few businesses before), and a database-driven web application to manage contact information for the company.
Being new to programming (having only written some BASIC programs in the past), I stumbled around trying to figure out how to connect a website to a database. First I tried plain old CGI stuff. Someone pointed me to Microsoft's Active Server Pages (it's free! Use Microsoft Access!! YAAY!). But at the time, I just couldn't get my head around how the languages worked. (Turns out later, this should have been a giant hint...)
Then, someone introduced me to ColdFusion. At the time, if memory serves, ColdFusion 3 had just come out. (Not a CFC in sight!) Ben Forta was evangelizing up a storm. Allaire would soon go IPO. The CF forums were on fire. Even though the product would cost money if I chose to use it, I was intrigued.
I went from "intrigued" to "SOLD" when, in a matter of 15 minutes, I had written a web page that pulled a record from a database, written some HTML for me, and spit it into my browser window. I'll never forget the feeling of empowerment as I went from that first experience to lying in bed pawing through the ColdFusion Reference Manual, looking at all the tags and functions. It was as if, one by one, they stood up in front of me and said, "And here's how *I* will do something really cool..." Each one was a little gift all its own.
I was hooked, and became a code-writing madman. Twelve hour days flew by. I was putting out web pages full of useful information, for people across the globe to see. I was doing it quickly, and my employer was praising the work. Yes, as a new developer I made all the usual mistakes... pound signs where they weren't really needed, misuse of functions, poor organization. But I was learning, and at the same time I was productive and useful to the company. Within a couple years, I'd published my first article in the fledgling ColdFusion Developer's Journal. It all felt absolutely wonderful, and I was making a living.
Fast-forward to the 21st century. Specifically, the past few years of my life.
Message board threads related Object Oriented programming in ColdFusion seem to rule the web-waves. There are OO gurus; there are OO training classes. There are even courses for MANAGERS in the benefits of OO -- for people that may not even be programmers. There are blog posts aplenty about how Object Oriented Programming can "save your project", make your team more efficient.
And me? These days I'm still busy as hell. Too busy, and too far behind. But I'm getting caught up, now that I've stopped hemorrhaging time and collecting frustration... now that I've blocked my near abandonment of the career and company I used to love. Yep, for all the work and associated revenue I've ALWAYS had, I nearly walked away.
I don't recall when I first got introduced to OO, but the first real step in the path towards near-destruction was an innocently-titled course I took, called "Java for ColdFusion Developers." It was being held in the Washington DC area, taught by someone that I trusted and could call my friend... a relatively well-known expert in the field that actually has a similar background as I do. He was assisted by his brilliant buddy -- a brainiac computer science and OO/Java expert.
I took the course because, well... because of all the promises. Not by the class instructors, but by the OO world in general. Promises that OO would make me a better programmer. I'd write better programs, faster. Modifications to my programs would break less code elsewhere. Insert-your-favorite-OO-buzzword-here would make my life so much better. And, I took the course because I was starting to feel like I was "falling behind" in the field... even though my bills were more than paid, business was booming, and clients were happy. The grass looked greener. And while the instructors did their best to keep the buzzwords at bay (and did so nicely), they were still there, in every magazine, on every web page.
As it turned out, for me, that greener OO grass on the other side wasn't even grass at all... it was Astroturf. It was a kind of fake, a fraud. Of course it was greener... it was sold that way. But it would not provide the pastoral comfort of the real thing.
I took the Java course, and while most of the OO marketing made sense, I finished the course quite frustrated. Not because the course was not taught well... not by any stretch. No, it was because "OO is a hard concept to understand... you have to think completely differently about things." (That's what you get told... it's a "paradigm shift.")
Okay... so I'll shift. It can't be that hard, can it? I don't have to know it ALL about OO ('cause you never can... you're told that too), I just need to know enough to make MY projects better...
So I persisted. The framework I'd used and loved for so long, Fusebox 3, by version 5.5 has become completely OO-based. That HAD to be better (right? RIGHT??!). It was pure OO - or at least, as pure OO as ColdFusion can get. It was just a given -- if you really wanted to do OO, your framework should be too. (Oh, you're not USING a framework? Heavens, what's WRONG with you?!)
Then things really got ramped up. Fusebox or Mach ii or Model/Glue? Reactor? Coldspring? Oh geez... what's a Service Layer? Oh my, so much to learn. But, I GOTTA learn it, though. Seemed like everyone was saying how if you really want to be valuable, make sure you "keep your skills up to date" -- and those skills had better be in OO because "that's where everything is headed".
So I piled all of that into my applications, little by little. My "skeleton" application structure -- my starting point for every new app, now had over 5000 lines of code, before a single line of code was ever written by ME. But that's what's going make things better, right? A whole bunch of code that does things for me? And it's all OO-based, so then I'll be more likely to "do" OO "properly" myself, right? And there's always more training classes...
But training in OO is a self-fulfilling, self serving thing, at least for someone like me... a musician who learned how to write ColdFusion code; someone who to this day is still giddy about the fact that I can write something in a file, upload it to a server 70 miles away, and then someone half a world away can read it... instantly. For someone like me, OO slowly started eating away at my "coding soul"... if I couldn't get something to work right using OO, then I "wasn't really doing OO"... so, back to the drawing board. More training. More books.
Over the course of 4-5 years, OO has cost me over $6000 in training and books, and a priceless amount of (priceless) time. OO took away useful tools in the ColdFusion world (I even had to turn off "Report Execution Times" in CF administrator, because my OO framework would slow to a crawl for some reason), in favor of harder to use tools that took more time to use.. If there even was an equivalent. It made my applications run slower. It made my interactions with clients more difficult, for them AND for me, because instead of looking at the problem domain for what it really was, it all become secondary to making sure I was "thinking OO" as we tried to hash it all out.
All of this was my own fault, I'm sure... because if things weren't working out right, then I probably wasn't doing "real OO". I was still not good enough, and I was convinced that my projects would suffer -- every one of them.
But OO did something worse than all of that... it eroded my confidence to the point of "work paralysis". Seems like everything had to be thought through, ad nauseum, to prevent "code rot" or writing myself into a corner, sickening amounts of refactoring. Lacking an OO solution that "felt right" for a specific challenge would mean hours of research, and the pestering of other gurus... because whatever I finally got right, I could most definitely reuse "next time". It was an "investment"... but each investment in extra time and research for the OO solution made me further behind.
The worst part of all, in 20-20 hindsight: Even if I knew how I would have solved a challenge outside of the OO lexicon, if it wasn't an OO solution, it wasn't going into the code. I wanted to know OO that badly. It felt like a real commitment, when all it was turned out to be Astroturf. How lame is that!?
Even though our application and database platforms had progressed -- ColdFusion 8 with MSSQL 2005 is a combination that can most CERTAINLY deliver a robust and feature-rich web app -- my own productivity in 2008 was the lowest it has ever been. Oh, clients were still paying... but now they were wondering why even smaller projects seemed to take so much longer.
But... Worst of all, OO took away the very joy of programming it promised to bring. This lack of happiness nearly destroyed my little business.
Yep, it was my own confidence and happiness. Not the economy (I haven't needed to advertise for work since I started), not my own lack of knowledge or diligence or effort. The lower productivity and the allure of that succubus called OO caused an undeniable lack of productivity, and an exponentially increasing level of daily frustration. I was truly, truly unhappy.
I decided to give this all one last shot. My friend, the one from the first training class, was offering a new one... nothing to do with Java. It was "Object Oriented Programming for ColdFusion Developers". This was it. I called my friend, and I told him, "This Is It. If I don't get this under my belt, I think I need to find another line of work, because this is slowly killing me."
For almost two months, I remained nearly paralyzed, waiting to go to this class. I was afraid to start EITHER of the two major projects I had lined up, because I was so afraid of the re-writing I might have to do after whatever OO epiphany awaited me. I stalled; I worked on smaller items I could deliver quickly.
Through fate, I had this friend all to myself for the week. (This was great for me, probably not so great for him.) We laughed, I learned. We talked about something OTHER than programming... often. That alone was therapeutic. I was introduced to a new way of working... a way that was empowering, a way that gave back some joy for all the effort that goes into building a web application.
But it took another few weeks before the actual epiphany. And when it came, it hit hard. My epiphany about OO had finally come, but it wasn't about OO at all. It wasn't about how I wasn't looking at objects properly, or modeling my domain properly, or about how i wasn't using a design pattern properly or extending my classes or using abstract classes or using interfaces or CRC cards or service layers or mixins or facades or my ORM properly.
My epiphany was really about ColdFusion. My epiphany is about the fact that ColdFusion was something I USED TO loving working with, and that it has been nearly ruined by the OO world, seemingly just because it happens to run "on top of Java." My epiphany was that I had listened to too many gurus, bought too many books, tried too hard to learn something new, in entirely the wrong context.
ColdFusion applications don't need "objects" and "OO" any more than Coke needs another f#$&*ing flavor. Coke is perfect the way it is. If you are craving an ice cold Coke, when you grab one, it TOTALLY satisfies. It is associated with fun times. It is perfect, Just The Way It Is. OO can too easily become that unnecessary new flavor of CF programming, and unless the circumstance really calls for it, it just isn't needed.
This hard-learned lesson made me really think about all the other people out there -- the ones that are just starting with ColdFusion, or are still just thinking about it.
I would wish upon them my experience from 1997.
And, I would do whatever I could to shield them from the OO marketing and buzzword BULLSH*T of the present. I'd block every website, every blog, about OO programming with ColdFusion. I would have them embrace what ColdFusion really is -- a tag-based language with some excellent features, all of which make you productive as hell. AS IS.
Here's another statement that's sure to draw some fire:
The worst thing that could ever happen to a ColdFusion developer is to take a Java class.
How could I say such a thing? Easy. Because ColdFusion ISN'T Java. I don't care how many new object-based features they pack into this language, EFFYOU it ain't Java. Taking a Java class will show you the absolutely wonderful features and benefits of a strongly-typed language. It will lead you down the path of Objects, and all the zillions of books and courses on the subject. You'll love Java. But then, you'll go back home and need to write things in ColdFusion -- either because, like me, you have to make a living, or because (like me!) you still love all the things that ColdFusion has to offer. And CF will be ruined for you in at least some small way -- you'll feel like somehow, the language is suddenly inadequate. Trust me, that's just the smell of the Astroturf... it's not real, fresh cut grass!
Take a course in Java, and you'll start trying to work like a Java programmer can, but in ColdFusion. But you NEVER REALLY WILL. The language doesn't truly support it.
Read all the books on how to think in Objects, and you'll try to make that all work flawlessly in ColdFusion. But you NEVER REALLY WILL. The language doesn't truly support it.
And even if the language DOES support it... you'll start to miss how fast you COULD deliver code, like ColdFusion was meant to do. You'll miss having control over your entire app, as soon as you jump on the buzzword bandwagon and start using a framework, an ORM, a dependency injection framework. It's all someone else's code. It all can slow down you or your app, or both. You Ain't Gonna Need It.
OO in ColdFusion is half baked, and I think it's that way for a very good reason... it's there to enhance ColdFusion, not CHANGE it into Java. Not to write 100% OO based applications. So Don't Try To Do It. I would imagine the smartest developers at Adobe would tell you this very thing.
Here come the flames...
"So what, Marc, are you condoning going back to the old days of spaghetti code, with no separation of concerns?"
Absolutely not. Absolutely not. Absolutely not.
What I am condoning is some f'ing sanity in the ColdFusion community. Some responsibility on the part of the OO enthusiasts and gurus to leave things alone until OO is really needed. Stop pushing the classes, the books, the websites, the design patterns. Stop being smug -- "Oh that didn't work? Then you're not doing real OO." Screw you buddy... I don't have time or money to take another class in unobtainable purity.
What I am condoning is that we teach new and established CF'ers some basic coding techniques -- MVC (yeah, I still dare to use a buzzword or acronym or two!) and that it's okay and even NECESSARY to go back and refactor your code OFTEN. Small examples of the most useful aspects from the OO world, and nothing more. And that refactoring is actually EASIER when you don't have your own code buried in a steamy pile of someone else's ideas about what a web app "should be" to be "right".
What I am condoning is that we teach new and established CF'ers that writing a web PAGE is just DANDY. A page... you know, A PAGE? like, when the web world began? Remember? Like, uh, product_list.cfm. Or product_detail.cfm. Or contact_form.cfm. Pages, that come from a file, the contents of which gets received and interpreted by a browser. Yeah... not /index.cfm/event/main.home or whatever strange stuff inevitably comes out of OO and framework overkill. A page, that you can go and open, debug, etc. using all the tools already available in the CF world. A page you can just open and modify and not worry about what objects are involved, who's inheriting from what, and what layers the data is going through to get to you... or what damned OO rules you're going to break if you have to change something quickly should the feces strike the ventilating unit. Oh and how this will tweak someone: If your page doesn't do CF at all, then name it .htm. "WHAT?!? No Way!" you say? Way. A page is a page. It's worked for two decades. Don't let the engineers ruin it.
Real OO should come out of NECESSITY in ColdFusion; it should not be the starting point, like it is in a true object based language. The starting point in a CF app should be the page. What do you need your page to do today? And, what does ColdFusion ALREADY OFFER that can make that happen, without thinking about "oh, well that thing on the page -- that is clearly an OBJECT." No, IT ISN'T. Not necessarily. Sometimes a kiss is just a kiss. Sometimes a bit of data is just a bit of DATA. Just do the damned table join using SQL - it'll fly compared to OO. Quit taking other people's advice and think for yourself... does it make sense to return one or a hundred objects to a Web Page, when a simple CF recordset will do? REALLY? More often than not, the recordset will do just fine, thank you. Your server will thank you, too.
The bottom line is, when you NEED to use some OO concept, YOU'LL KNOW. *That's* the time to start writing OO-style code, and only then... not everywhere else. And the moment you start downloading one framework after another, piling them all into an application, because someone said "use this, your projects will go faster"... That Should Just Feel Wrong.
What's ColdFusion good at? Recordsets. Querying a database, and handing you effing data, formatted as HTML or JSON if you like. CF is good at taking a web GET or POST and turning into an insert or an update in your database. Sending email containing data. It's really good at that stuff, and a LOT more. I should know... I've been using it since version 3. And now at version 8, it's good at so many OTHER cool things too. More than any other application server in its class. None of which requires getters, setters, a front controller, inheritance blah blah blah zzzzzzzzzzzzz.
Saving and retrieving data. Creating dynamic PDFs. Image manipulation. Messaging. File-based data management. Even some cool report building. What do most apps call for? THAT STUFF. You know, that stuff you can do with a .cfm page and some CF tags... maybe some CustomTags if you like. Perhaps some centralized controllers for your pages to talk to, so you still have some good organization.
Don't turn a row in a database into an object "just because". If all you need is a recordset, then by all means, use a damned recordset. If all you need to do is validate a form post and store it, don't send it through three layers of crap and a zillion objects to do it. It's pointless.
"But Marc, I bet your apps are hard to maintain."
Nonsense, pure and simple. In fact, it's easier to maintain an app when you don't have to go through 10 templates to figure out what the app is doing to your form data. And a business client can tell me what PAGE they are on when they have a problem. A page name -- go figure! I'd be willing to bet the majority of apps that the CFers out there are writing, or at least the mini-apps inside the larger ones, really are THAT SIMPLE. QUIT GUMMING THEM UP WITH OO, slowing down yourself and your servers. Unlike Java or C, CF is terrible at creating an Object - it has to work pretty hard to be that type of God. It's Slow. So don't do it, unless and until you really really need to.
MVC and "diligence in refactoring" when things start to feel wrong or unclean. Well thought-out specs, in advance of the first line of code. Decent standards compliance in your views. That's what OO gurus might consider teaching CF developers. Objects don't own the market on these concepts. Save your Singletons, your Dependency Injection Frameworks, your Frameworks, your Design Patterns, all of that, for when a developer presents a specific problem and wants a clean way to solve it. If the problem calls for any of those things -- truly calls for it -- THEN you may bring it up. But not a moment earlier. Teach through specific context, not by buzzword and framework-download mania. Write a blog post for each example if you have to... it's better than tome after tome about the OO world. And quit being smug about your knowledge of OO - it's not helping anyone and nobody cares if your app is pure OO. Sorry.
"But Marc... you're an idiot for having let things go so far that it was going to ruin your career! You took it all too far!"
I couldn't agree more.
But remember, it didn't happen overnight... it snowballed, just as the OO world crept into the CF world, a little at first, and then suddenly took over with all the vigor of a 15 year old boy getting his first dry hump.
And consider this... if it happened to me -- someone with a fair amount of intelligence and common sense (yeah, I guess I do have some confidence back) -- it could easily happen to others. Especially young CFers that have fallen (wonderfully!) for the Adobe marketing of ColdFusion, or those folks that just don't come from a Computer Science background. Their new programming minds are so impressionable. Don't screw them up with the OO drug.
Perhaps, as my friend has alluded to, it was my personality type. Not uncommon, really. As a musician, we strive for excellence. The only way to truly achieve it is through complete immersion in your instrument. Wire and wood is all my guitars are... to be a true instrument it requires ME. So I went to school for music. Learned history, theory, performance. Practiced 8-12 hours per day. Completely immersed myself in the instrument. The practice was always more valuable than the theory, by far.
My approach to programming was the same. I wanted to immerse myself in it. But instead of immersing myself in my chosen language, without noticing, I had become immersed in the theory. I stopped "picking up the instrument" in favor of reading about all the ways it could be played. And then when I finally did pick it up, it no longer brought me happiness, because all the theory was telling me that what I was writing wasn't going to be good enough.
That was the Kool-Aid I sucked down, little by little. It was a slow poisoning, that up to the last moment felt simply like blissful intoxication. Don't fall for it!
My career didn't "Almost Die" because I had no clients, and no ability. It almost died because I was somehow reaching the conclusion that I wasn't going to be good enough to sustain my success. I was worried about becoming marginalized by the OO programmers. So "OO programming" was the catalyst for that wholly incorrect conclusion.
If you've read this far, maybe you know the feeling... "Eventually the OO programmers (from India?) are going to be able to deliver projects like the ones I do now, in half the time, and maintain them at a fraction of the cost, and I'll have to go back to selling cell phones.. perhaps out of a kiosk at the Carousel Mall... because eventually, nobody's going to hire a non-OO programmer. I'm not doing things the right way, and unless I get this OO thing nailed down, I'm going to eventually fail."
Extreme? Maybe a little. But that was the logic. As a single hired-gun, my success almost seemed too good to be true, and OO was going to give me some security. I would start doing things "the right way", as told by all those brilliant minds. And if I didn't, I would eventually lose out.
What a pantload.
I now say Wake Up, CF'ers. When you've delivered a working project that's 99% (or more!) your own code, does what it's supposed to do, and for which you've just received a fat check... believe me, you've done it the right way. And with ColdFusion you CERTAINLY don't need OO to do it.
The fact that I couldn't quite grasp ASP as a newbie should have been a clue -- they talked about objects, even back then.
When I left the Java class frustrated, and later realized that I loved CF too much to abandon it for Java/JSP... that should have been a clue.
When it got to the point where I was starting out projects with a METRIC TON of code already written for me, that should have been a clue.
When I was spending more time trying to figure out design patterns than what the latest features of CF8 were, that should have been a clue.
When I started hating my job... when I couldn't deliver some of the more simple things... when I was feeling really depressed and actually considering leaving an otherwise thriving business... all clues I missed. When my friend, who was initially a huge OO proponent, disappeared from the community... that was a much more subtle but way more important clue.
I have my friend to thank. The last "training" was still about OO, but it brought about a sea change in common sense. Especially for small non-Computer-Science programmers:
-- Use OO when necessary, and not a moment before.
-- Don't use OO at all if you don't have to. (I recently told him I had just architected a fairly involved but completely well organized project, without ANY objects... and I was almost afraid to tell him how GOOD it felt... his response? "Imagine that." After which he proceeded to demonstrate how he'd recently done the same damned thing. HAPPILY.)
-- Don't buy tons of books and training courses covering every aspect of OO, hoping it'll make you a more valuable CF programmer - people couldn't care less, clients especially. Don't kill your productivity that way. Instead, put your energy into learning what CF can do... bury yourself in the manuals for the product itself -- seems there's always some new little discovery waiting there for you.
Exhaused that info? Really feel the need to expand your mind? Great! Move on to the real meat -- nothing's worth anything if it doesn't LOOK right. Take a design class; concentrate on your look and feel, your usability. Take on the challenge of a fully validating XHTML page, and make that page come from your app. Maybe every page. Take on the Section 508 accessibility standards. Your diligence in those areas will TRULY pay off, and it will keep you busy, if that's what you feel you need. Get obsessive about stuff that REALLY matters. Exhaustive OO in CF will merely punish you, and your server.
-- What REALLY matters is building a sensibly organized application that works, under a reasonable budget and timeline, and committing to refactoring when things feel even the slighest bit messy.
-- Understand that when you start using someone else's code on a large scale (i.e. a framework upon which you build EVERYTHING), especially FREE code (another rant for another day), you are accepting THEIR shortcomings into YOUR project. And when something breaks and you can't figure out where to fix it, they have NO real incentive to give a response to even your most urgent requests. How much time have you REALLY saved? Really? Not as much as you think.
-- Set your own standards for how you wish to build your web apps. Refine them with each new app. Borrow from others only what you fully understand and can incorporate into your own standards. Document those standards. They'll come in handy if and when you DO have to integrate the app into a team environment, or if you have to turn your code over to another developer. Strive for consistency in your app, and document it. You don't need OO to do any of this. The difference between an amateur and a professional is consistency and documentation... and OO Programming doesn't have the market on either one of those concepts, nor can it deliver on any promise it might make that you'll achieve them any better than without OO.
ColdFusion gives you the ability to do all that you need to do to deliver a high quality web app, "out of the box", with ZERO OO required.
Given this new line of thought, I now feel totally confident knowing that if I had to go back to writing in CF 3 tomorrow, where objects where unheard of and Jeremy Allaire and friends were simply jammin' on adding more useful tags and functions to the language, it wouldn't change a damned THING (though I'm sure I'd miss CFIMAGE and a few others :). I'd be just as happy... and so would my clients. And my bank account would still remain in the black.
I'm not saying OO is evil and should never be studied, even by CF'ers. There's some good stuff in there. I just think OO is for WAY FEWER ColdFusion programmers than anyone doing CF OO wants to admit, and only then a small subset of the OO lexicon ever really applies.
If you're really groovin on OO and jonesin' for true, pure OO programming and it's related tools, and you already kinda grok it, then put down the CF manual and slowly back away from the server... you want Java. It's the next door down on your left. Help yourself to an Oreo on the way out.
But if you really love CF, and your CF server, then PROVE it. Fire up your editor, create a brand new EMPTY directory, and write a ColdFusion WEB PAGE. I dare you. Go on... the world will keep spinning, I promise... and you might find that you CAN get back that feeling of power that made you fall in love with CF in the first place -- how quickly you can write something truly useful, and FEEL PROUD of what you've just done. Oh, and you'll probably be happy and productive and make money and spend time with your family and have a hobby. :)
Shoot the engineers, and begin production.