Objective Bias

Wow. It's really been a while since I've posted anything here. What has finally jolted me out of my blogging inactivity was Ray Camden's latest blog post. Therein, Ray shares an email from a beleaguered CF developer ("Keith") who seems to be wondering if he's missing out by not being up to date on all the latest CF frameworks when he seems to be doing fine with "relatively simple CF code and CFCs."
The gist of Ray's sage advice is to basically do what works for you. If you find yourself to be an effective developer who delivers quality products without the use of a framework, then you're not missing anything. Basically, frameworks are there to solve problems. You shouldn't be looking for problems just for the excuse to use a framework. Ray uses his adoption of the Model-Glue framework as an example and explained how it specifically addressed a problem he had concerning how to organize his code.

However, even if you choose not to use a framework, Ray went on to recommend "being aware of OO, design patterns, and the like." This, I think is where some beginners may get stuck. Ray himself commented on how there's no way he would've "gotten" how and why to use delegates just by reading about it -- he actually had to see it in use in a real project. "So," the OO/design pattern beginner might ask, "how will I ever 'get' this stuff if I've gotten along fine without them?" My answer would be to force yourself, if only to learn it.

A couple of years ago, I was in the same boat as Keith. I didn't know anything about frameworks, OO, or design patterns. Even though I was unsure about whether they would be useful to me, I knew for certain that I couldn't even make that assessment without learning about them. So I set about searching and devouring all I could about OO in CF from blog posts, articles, CFUG presentation recordings, forums, mailing lists, books, you name it. But, as Ray said, reading about it isn't enough. At first I hemmed and hawed about the "right way" to use objects. But the best piece if advice I got was to just do it. I was assured that my code would suck at first (which it did), but that it would only get better with experience. So I did it. Even with the simplest of applications I would put together a service layer which called on beans, DAOs, Gateways, and utility objects. I was writing a crapload more code than I used to and it did seem like I was going all the way around the world just to go up the street. But unlike Keith, who tried to make sense of having a 2000-file framework-driven "hello world" app, I was going in with eyes wide open KNOWING that I was slavishly using every design pattern I'd read about just to get my hands dirty.

And it worked. As I got more comfortable with my new tools, I started to gain the ability to recognize when certain patterns were called for and when they weren't. I started to see the value of objects first hand, and the advantages they provided when it came to code maintenance. And I went from using objects the way I'd read how other people use them to using them in a way that's more natural (for lack of a better term) for me. All the while, I still educated myself by keeping up with the blog posts, mailing lists, forum posts, and presentations. And it's great when you actually start understanding the jargon! Experience, however, is still the best teacher. Just as I cringe when I think about those first "OO" apps that I wrote, I'm sure I'll someday look back at the code I'm writing now and wonder what I was thinking.

So, I still feel like I have a way to go. But I also feel that I've experienced a heck of a lot of growth as a developer over the last couple of years. So for those people like Keith, I'd encourage you to just do it. The CF community is small, but fantastically helpful. There is plenty of info out there to get you started and there's the CFCDev mailing list. You might come to the conclusion that OO isn't your cup of tea, but at least you'll do so from a position of knowledge. And I guarantee that you'll get something useful out of your quest for that knowledge.