Two items crossed in my mind to form tonight's post. I was watching a PyCon video about Tests and Testability in which Ned Batchelder said "You will write testing framework code. It's okay, it's really not a big deal. Just do it." This was followed a few days later by a Riding Rails article by David Heinemeier Hansson (from 2005 no less) about his dislike for componentized login systems.
Underneath DHH's argument is that you will be spending time implementing the solution to your problem of needing to track user authentication and authorization. This time and effort would probably be better-spent implementing a custom design that takes into account YOUR needs rather than trying to coerce someone else's solution into a half-solution. In reconfiguring, altering or encapsulating your use of the component you are going to end up writing authentication and authorization framework code.
Something that's pushed me towards automated testing and continuous integration topics is this same idea: if you're already going to hand-test the application after you've made a change, why not encapsulate that test into something automated? This drive alone, however, leads to the realm of components (or middleware or JARs or whatever it is in your system) that results in the weeks that I've wasted trying to get some software package or another, dictated by my employer, to work for us.
I'm usually not a champion of the school of thought labeled "Not Invented Here syndrome" but I do feel that homegrown solutions tend to be shaped by the particular problems of that home. If you work in a place that has weird firewalls, your solution will probably deal with firewalls better (for your value of "better") than something else. If your developers include some that use Linux, Windows, and Mac, the development tools you use will either come prepackaged as multi-platform or you will grow your own development tools that can survive each system gracefully.
The trick is to not get hung up on whatever your work environment's curses are. I run into this in regular life too: my teenage son gets really upset that he has to have his work checked, and then to re-do any work that's incorrect. To him, that's not part of the contract. When he finally accepts that checking the work and fixing it if it's wrong ought to and WILL happen every time, he'll have an easier time with it. Does that sound like what you've heard about unit tests?
But I'm a tester! I don't write code!
You will.
I'm a software developer, I don't deal with customers!
You will.
Alternate answer: You do! My customers are the support staff of my company.
I'm the President of the company, I can't deploy the website.
You ought to. What if Mutt & Jeff are on vacation? See the PyCon video "Why not run all your tests all the time?" by the excellent Dr. C. Titus Brown. He convinced me.
