
The Framework Myth - fogus
http://mooneyblog.mmdbsolutions.com/index.php/2010/12/07/the-framework-myth/
======
thinkingeric
"They were not built to solve a business need"

That's not quite correct. It is perhaps more accurate to say they weren't
built to solve your primary business need. They certainly solve the problem of
getting unskilled people to be productive at some level. And this is not a
trivial consideration. It takes a great deal of effort, time, and expertise to
design a system that maximizes programmer productivity, such that an ideal
minimum number of 'programmer-hours' is all that is required to augment and
maintain it. And when you do, it is likely that it requires 'wizard level'
programmers to put in those hours. Expertise is expensive, hard to find, and
presents a certain replacement risk for an employer.

The alternative is more dumbed-down systems. The code is less elegant or
clever, but easier to understand and imitate. And the 'brutish' nature of such
code leads to a certain amount of repetition, which requires more 'programmer-
hours' to work on. Hence the need for more developers. As many folks have
pointed out, programming today is very much a social activity. The systems
themselves are partly responsible for this. There is a need for developers to
be 'hot swappable'.

And the staffing pressures are partly what are responsible for the popularity
of frameworks, for similar reasons. Frameworks are development languages that
sit on top of programming languages. In many cases, you barely even need to
know the underlying programming language in order to produce fairly
sophisticated results. In contrast, to be productive in programming languages,
you need to have a fairly deep understanding of your craft and have a good bit
of experience in the quirks of that language.

Frameworks are like DSLs for a technical domain. While it can take some time
to learn the framework language, you can produce more, faster than if you have
to build software from scratch (or using just libraries). But what are you
producing? As the author says, they are built for "20,000 or 200,000"
developers. Not you. And not your problem. They may solve common problems, but
they don't necessarily solve your particular problem in the most appropriate
way. You may need to rethink your problem to fit what the framework can
accommodate. Or face the staffing dilemma.

------
knowtheory
The problem with companies building frameworks boils down to one simple fact.
If a company is unable to differentiate and disentangle it's goals from the
goals of building and maintaining a generalize and useful framework.

Companies can build frameworks around solid principles and know when to let
them go and develop into community projects. Rails certainly developed in that
manner. Likewise, Sproutcore developed for a while under Apple's care, but has
also split off, as Apple's goals diverged with sproutcore's.

If you are going to build a project for developers, make sure you have the
developer's goals in mind, and not your own. Same is true of building an API.

------
verysimple
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.

------
Shorel
There's a HUGE difference between the .NET framework, that is more a Library
of classes, and for example the PHP Cake framework, that really takes all
control flow out of the hands of the developer.

In other words, I'm still so old school that I prefer a good library of
classes, functions and tools, than the newest I-will-write-all-code-for-you
framework.

In the same way, I feel better if I write a library that can be used by any
project for a very specific feature (like localization, or disk cache, or
something similar) than if I write a framework where everything should be done
in the framework way and most logic should be rewritten.

