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.
tpryan.blog 
This is a great perspective, Terry, and seems quite logical. What to do, then, when all you are is “weak spots”? 🙂
LikeLike
>> What to do, then, when all you are is “weak spots”?
Pick something. Learn it.
LikeLike
I like that you cleared that up using the 80-20 rule. Almost certainly in the case of an ORM you will be more productive using it that writing your own stuff, and it will be useful for (likely more than) 80% of your cases.
But (not sure why this font is getting big, but I put a space in above and it seems to have gone away) I would caution not to just assume that “my solution is better than theirs” because that is your expertise. That may be true – but your solution may still take longer and produce something better than “good enough,” in which case, you’ve still wasted your time.
To me, Joel’s article read more about not outsourcing your primary business function – not your primary talent. So for instance, if you were selling data mining services, you might want to write your own applications for it. But, if you can make use of Reactor (which, you may or may not be able to do), then you still might do that. But, if you were selling ORM frameworks, you might not want to use Reactor to do it. That’s how I took it anyway. I know the Excel example didn’t focus too much on that – but they had other, internal reasons for not wanting to use others’ code, that I’m not sure apply to this situation as well as they might to others.
LikeLike
In any case, the point of the framework is to assist you. If you run into to points where you are fighting it to do what you want to do – then you should be able to drop out of it for a second and just do what you want to do. That doesn’t mean you would completely give up the framework, however. You use it to build what it can, and ignore it for the things it can’t.
LikeLike
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.
LikeLike
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.
LikeLike
I have to say the same, I would love to be more efficient, and I personally haven’t seen a framework that screams to me, yep this is the one for you.
What bothers me the most about framework’s is the proselytizing, everyone does, implying your a sucky programmer if you don’t program with a certain framework or any framework.
I think there are things we can learn from frameworks, but me, i am still waiting for the fish to come and bite me.
And I do like Joel Spolsky, he has a lot of common sense, also like Jeff Atwood’s Coding Horror.
I mean, good architecture helps, unless the creation of that architecture gets in the way of you doing your job.
LikeLike