Aarrgghh!!

Yet another Framework Post

I know, I know, we don't need another framework post. But the latest posts from Sean Corfield, Brian Rinaldi, and Jake Munson make me want to speak up. While I'm naming dropping, I feel the need to cite Joel Spolsky's In Defense of Not-Invented-Here Syndrome.

I am not against frameworks. I've tried coding against a couple. I've at least looked at most of them. I don't currently use one. The one I got the furthest with was Model Glue 2. I like it a lot, but I'm just not productive enough in it yet to rely on it. That means that I can accept that Joe Rinehart came up with a better solution to my problems than I, but I can't use them as productively, as I can use my own, perhaps flawed solutions.

It's that bit of logic that I think should be the key to using frameworks. Use them where they will be more productive than your own efforts.

Follow what I mean here.

Let's say you are a database wiz. You design textbook perfect databases in your sleep. You love seeing execution plans with no table scans. You think it's cool when your queries have to use parallelism. It would not be in your best interest to use a database framework like Reactor. Why? Because you would be substituting Doug Hughes' judgment for your own, where you provide the most value.

Well that's not quite true, because you don't exercise the full extent of your knowledge on every single piece of SQL interaction code you write. If Reactor makes 80% of what you do take 20% of the time it used to, then it still might be worth it to use, and then manage the exceptional cases.

Okay, I haven't convinced you - you still prefer the way you deal with your database to the way Reactor does. Okay, but you're still probably doing a lot of repetitive, rule based code like writing <cfstoredproc> code blocks with are more characters the actual SQL stored procedures you've written. Perhaps you should write your own code generator. That's essentially what I did with Squidhead, and it was easier than I thought, and a great experience for me.

Okay, database wiz, now it comes to the UI. You need to do an Ajax front end. What do you do? Start writing JavaScript? No! You told us you were a database wiz. If you're not a JavaScript wiz then stop and download an Ajax framework. Because at some point someone has better judgment than you about some of the technology you use.

Now I started with a database guy, but I could have started with an Ajax wiz, or a designer and the advice would have been analogous.

If your expertise is based on a certain set of skills, you would be nuts to accept someone else's judgment for yours. But if you're not an expert in an area, that it is equally nuts to assume your judgment is better than an expert.

Pick frameworks and techniques that strengthen your weak spots.

February 17, 2007 Posted by Terrence Ryan at 8:15 PM

ColdFusion, Web Development,

Comments

Sammy: I admit that I am extrapolating from Joel's piece, but I think that the logic is still sound. Don't let someone else do what adds value to your customers. I would also add, that someone who has a better way than a particular framework, could still be better off, if they automate their own "framework" instead of using someone else's.

Posted by: Terrence Ryan at February 18, 2007 10:42 PM

Joe: Ironic that you would ask that, being as you're an expert in some pretty diverse areas of knowledge. But I would say, at some point you're going to have to add value to the people paying your fees/paycheck. So if you're just weak spots, then get rid of one... fast. But I'd argue that people that are all weak spots technically speaking, usually provide some other value to the people that pay them. In which case they should defer to technical experts for everything technical, and leverage their soft skills to add value.

Posted by: Terrence Ryan at February 18, 2007 10:46 PM

Post a comment