Nice article. I agree 95% (I always give myself 5% in case I change my mind later about a few things ;) I once got hired in a company where I found that a deve

Nice article. I agree 95% (I always give myself 5% in case I change my mind later about a few things ;) I once got hired in a company where I found that a developer had convinced the management of letting him build a framework. Since our boss swore by this guy, we had no choice but to keep using his pile of garbage. I've subsequently used various frameworks and have had various frustrations that with time I think I can pin point. Here's my list of recommendations for people undertaking the next life changing framework out there: - Always start by asking yourself "Am I nearly as good as I think I am?" - don't try to fix the world with your framework. Stick to the 80/20 rule. Simple tools that solve 80% of problems efficiently and unambiguously. Leave it at that. Please, pleeeaaase don't venture in the other 20 - provide damn good APIs and hooks to extend your base libraries. - make it equally easy to avoid using your libraries. If your library is meant to be used by somewhat smart and responsible people, do your very best to keep them in charge. You may recommend against certain practices, but don't you put safeguards that prevent me from implementing the occasional hack. - document both, how to do it your way and how to go around. - document your framework's capability as well as limitations. I have no clue why most library authors avoid talking about limitations. They know what they are and they know people will ask about them, yet they don't document them. If your ORM lib doesn't offer a certain facility, please just tell me. Spare me the countless fruitless hours of searching google and irc. Let me know I need to go down to sql, I won't mind. Don't just hope that I will never need to use it in my life and leave me hanging. Tell me. TELL ME.