I'm sitting in a co-working facility and listening to a couple of engineers behind me. They seem to be working on an application in Rails that involves doing role-based security. I'm not sure exactly what the application does, but they keep saying things like: "Well, admins can see every user's profile. And members can see the profiles of other members of the same group. And guests can see only profiles marked as public." All in all, it seems pretty straightforward. I don't know Rails personally, but my understanding is that it's just fine for stuff like that.
But about 5 minutes ago, the conversation took a bit of a scary turn.
Developer A: "Well, I had to do this weird hacky thing to make this role see this object."
Developer B: "Hmm... but we're using devise" (a common Rails authentication solution)
Developer A: "And then once I did that, I had to do this other weird thing, and it doesn't really want me to do it, but I managed to coerce devise into letting me set this attribute here. It's all kind of brittle, but it seems to work."
Developer B: "Hmm..., but we're using devise"
I'm with developer B on this one.
The minute you say, "had to do this hacky thing" when you're not doing anything unusual, you've got a massive code smell. As long as what you're doing is within the opinions of the tools and framework you're using, then you should be able to do it without resorting to hacks, coercion and bypassing the very framework you're trying to take advantage of. Role-based security, by the way, is well within the bounds of what the devise framework can handle (promise).
And that's the overall lesson.
Most of the things we do are in no way unusual. There should not be a need to hack in most situations. Make sure that your problem is really truly unique before you go beyond the normal way of doing things for your framework.