

Love-Hate Relationship with Frameworks - kenshi
http://logiccolony.com/2010/10/29/Love-Hate-Relationship-With-Frameworks.html

======
bradleyland
There are some titanic-sized caveat that applies any time you start having the
"there's a more direct way of doing this", or "this doesn't fit the framework"
conversations.

Whether or not you agree with the philosophy of many of the existing
frameworks, the people who are writing them develop, think, and live at a
higher level of abstract thinking than most developers. If you look at the
total pool of developer talent available, only a small portion ever write a
successful framework? Why is that? Because writing a framework that is, at the
same time, flexible, fast, and powerful is incredibly difficult.

I can't tell you how many times I've sat across from the table and listened to
someone tell me how their problem doesn't fit pattern X. In most cases it's
true there is a more direct way to accomplish a task, but patterns aren't
designed to provide direct solutions, they're designed to structure your code
in a way that makes it modular and easy to maintain.

When you deviate from the path, you better have a good reason, because you're
often trading a lot of things that aren't immediately apparent: abstraction,
consistency, maintainability, and portability.

------
ollysb
When people start working around the public API by calling private methods
it's because the framework is being used in a way that wasn't planned for. If
we could adapt the public API to provide the required functionality then the
framework would over time become more adaptable. The issue then becomes a
social one, how to organise and consolidate the customisations that everyone
makes. Github uses the forking and pull request functionality to address
exactly this issue. It allows developers to maintain a version of a framework
with their own customisations. Any of these customisations that would be
useful to enough other developers can then be incorporated into the original
framework.

