
Why I Hate Frameworks - Jebdm
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
======
arockwell
On a related note, I saw this on reddit this morning:
[http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...](http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html)

What's sad is that I have no idea if this is a joke or not.

~~~
jimbokun
Perfect thing to show people, when they want to know if Java is a good fit for
their problem. Even a Pointy Haired Boss, shown this, might understand why
Rails or Django or something might be a better way to go than dealing with
this.

EDIT: OK, so instead of Java, that should read "to know if enterprisey Java
frameworks are a good fit for their problem." The irony is, that I just was
IM'ing a friend about how this isn't the fault of Java the Language, but the
"enterprise architecture" community that write Java frameworks like this.

~~~
dgabriel
Java is not the problem, the architecture is the problem. If you try hard
enough, you can make something unwieldy and atrocious in ANY language. That's
why enterprise architects get the big bucks.

~~~
chaostheory
That may be true, but it's a hell of a lot easier to make fugly spaghetti in
something statically typed like Java (or C#, C++, and so on).

After 8 years of Java, I personally found it really refreshing to build stuff
in Python and Ruby.

~~~
dgabriel
I don't know. After seeing some pretty unbelievable crap in VB, php, and
javascript, I bet it's more a matter of numbers. The kinds of people who
program in Python or Ruby aren't off the assembly line because the industry
demand isn't as high. If one of those languages manages to become as widely
used as Java, plan on seeing fugly spaghetti.

------
mdasen
Frameworks can sometimes be annoying. It's like learning a new sub-language on
top of the programming language as there is a certain amount of familiarity
you need with a framework's calls (ex. to program in Python, it goes a lot
faster if you know that it's len(list) not list.length() and similarly if
you're using Rails it's important to know that there is no
validates_is_number, but there is validates_numericality_of). So, you start
learning all these things that may or may not apply to your project - the
language of the framework. And in some places it slows you down and you feel
like there's abstraction just for the sake of abstraction, but in the end I
think it's worth it.

I also think Joel misses something: most programmers are bad programmers.
They'll dig you into holes, write lots of spaghetti string code, etc. At least
when they're using a framework there's some constraint on their madness.
Frameworks (generally) make it a tad difficult to work outside of their
constraints and so the default becomes to work in that standard way. So, you
don't get people doing weird things as often - like building a string that is
the page that they'll echo out like the piece of PHP I'm working on today does
(guess they didn't realize that you could simply go out of PHP mode to do
that).

~~~
clintavo
I guess I'm one of those bad programmers who does "weird things" , I often
create a string with my entire page and then output it. I thought it made more
sense since I now have a string that I can run regexes on or find/replace if
necessary. Also it makes it easy if I decide I want to cache the page
somewhere, I think I must be "dumb and gets things done."

~~~
Ramone
PHP (I assume we're still talking about PHP) has had output buffering for
about a decade. So yeah that is a weird thing. ;)

------
patio11
An oldie (2005) but goodie.

Although it is less about frameworks and more about a disease which was
largely contained to Java enterprise-y architecture stuff. (I say as a
practitioner in that field... remind me why we are using the Factory pattern
here, again?)

~~~
fizx
In fairness, the Factory pattern is useful when you want to unit test classes
with mocks. In dynamic languages, this is easy, but more static languages
require jumping through hoops.

Alternately, you could use something like Google Guice, but that's (sorta) a
factory-factory.

Basically, no one likes the situation, but they've chosen their tradeoffs,
which they see as the lesser of N evils.

------
justindz
A friend convinced me to try AppFuse once. I have a burning, probably un-
justified hatred of Eclipse, so I tried the AppFuse + NetBeans tutorial.

That may be the most unproductive I have felt in my entire life. I made a damn
login form and it took like 12 pages of tutorial, tons of setup, generating a
whole bunch of files that seemed like they could have been done
algorithmically because they are always the same, editing like nine different
XML files with little bits of glue, and eventually like one or maybe two lines
of code.

Then, I got to wait for the WAR to compile each time I wanted to test a
change, because the tutorial didn't seem to know about a developer mode which
probably exists.

I hate to sound all ranty and partisan, but I could find no way in which that
process could be efficient and couldn't imagine anyone doing it voluntarily
unless they were ordered or just had no exposure to the rest of the world.

Also, I sort of object to having code stuffed in an eight-folder deep
hierarchy where the preceding seven folders contain nothing at all. That's a
lot of wasted navigation and clicking time and distraction.

~~~
arockwell
There's most likely a developer mode, but that's only good for reloading a
change to a Java class file. Reloading an xml file will still take a restart
of the servlet container. I agree with you that there is basically nothing
efficient about the entire process.

------
stcredzero
Over-complexity is common in the Java space. I was aghast at using JMS. You
make a Context so that you can tell it to make a ConnectionFactory, so that
you can then ask that thing for a Connection, _then you finally get to login_.
You can then instantiate Producers and Consumers and finally get messages.

Why do I need to have 5 different objects when one would do? Having 5
different objects did absolutely nothing for the client code except make it
more complex. (And this actually complicates good coding for the user
experience. When we notify the user of network problems, I have to add
additional code to see if objects exist in the first place just to prevent
exceptions.)

It would've made no difference if there was just one Object. (Except for
shorter code.) I could use it to login to a server. I could use it to register
interest in a topic then ask for messages on that topic. If I want to connect
to a different server, then I could instantiate a second object. Why do I need
5 freaking instances to do the most basic thing possible?

~~~
arockwell
This also makes unit testing extremely diffcult since you have the joy of
creating mock objects for your Context, ConnectionFactory and Connection. I
have all but given up writing test code at work. The various j2ee frameworks I
have to use make it almost impossible.

~~~
st3fan
Drop Classic J2EE and learn Spring. It will make things sooo much easier and
manageable.

~~~
mattmcknight
It definitely does make the above more manageable, but it doesn't solve the
core problem which is that the whole design pattern is built for complete
configurability, but without sensible defaults. In some sense, Spring only
exists to manage the massive configurability of Java design patterns, but by
adding it's own configurations to the mix. It's definitely a cool idea, but
the better solution is to just avoid factory/context patterns. It's solving a
problem most of us don't have.

~~~
st3fan
"""It's solving a problem most of us don't have."""

I think that is because a lot of people simply don't know what good design is.
I've seen many projects where people think they don't need Spring but where it
made 100% sense. And made the project simpler and easier to manage and test.

Even in small projects it makes a lot of sense to have a good seperation in
layers or services and to use a _mostly_ invisible helper to glue things
together.

Modern Spring can configure your app with a very minimal amount of XML. If you
don't like XML then use annotation based configuration.

I totally disagree with your statement that Spring only exists to manage the
'massive configurability of Java design patterns'. The only patterns that the
foundation of Spring introduces are IoC and 'configuration by convention'.
Those have been proven to be extremely powerful patterns that simply allow you
to burn half of the 'J2EE Design Patterns' books.

------
DanHulton
Frameworks - used properly - can be INCREDIBLY helpful.

Why develop my own routing code when there's already a robust, well-tested
version available? Or validation code? Or payment authorization code?

Though it needs to be said that the number one thing a good framework does is
GET OUT OF YOUR WAY. I've seen some Java frameworks that take an hour to put
together a simple Hello World and that's just nonsense.

Currently I'm using Kohana, which is nice because it's really very simple and
easy to extend. So far I've been able to spend so much more of my time
actually writing business logic instead of routing logic and the like.

~~~
mattmcknight
Unfortunately, JSR-168 compliant portlets are perhaps the crowning example of
horrible implementations of an insane standard.

------
swombat
Rails: Here's a kick-ass hammer, a kick-ass saw, a kick-ass measure tape,
etc...

Oh, and if you need them to be different from the default, you can modify them
as you want, but we think the default works for most people.

~~~
statictype
But don't bother checking for the spring mechanism that retracts the measure
tape in case it breaks or the power supply connection point on the saw if it
stops working.

Those bits just magically work!

:)

~~~
swombat
They don't magically work. You'll understand the mechanism when you know a bit
more about how to build a measure tape and a saw. Also, all the so-called
magic is extensively and automatically tested, and so an order of magnitude
more reliable than your own custom-rolled spring mechanisms.

~~~
nailer
Exactly. This is why the article is such a bad analogy - frameworks makes
things simpler by handling things you'd already do without them.

If you're making a spice rack:

Without framework: DIY shed filled with tools

Framework: IKEA

~~~
swombat
Well, not quite... that's a bad analogy too, actually... Rails isn't IKEA -
and most java frameworks are definitely _not_ IKEA.

Frameworks are tools, not end products.

~~~
parenthesis
Have you tried assembling an Ikea flat-pack?

~~~
swombat
Many times, and I can't for the life of me understand why anyone would
struggle at it.

IKEA provides flat-packed products. You never buy a wardrobe at IKEA and then
turn it into a couch instead. It will always be a wardrobe, and nothing else.

On the other hand, if you buy a set of tools and environment (aka framework)
to build furniture, you can use it to build whatever furniture you want/can.

------
st3fan
I stopped reading after "In the process, I'm evaluating a bunch of J2EE
portlet-enabled JSR-compliant MVC role-based CMS web service application
container frameworks."

~~~
ynd
That was humor :)

The rest is funnier. Give it a try.

------
nihilocrat
The more people talk about J2EE, the more I think it was invented to give
programmers busywork and multiply their workload with no increase in
productivity.

~~~
snorkel
Sort of reminds of project management software: it's just there to keep the
project manager busy.

------
dasil003
The essay itself is funny and rings true, but then in the comments the author
says:

 _"What I'd really like to find are some appropriate libraries that I can use
to provide several kinds of functionality for my project."_

And then lists a bunch of high-level website functionality requirements (user
accounts, content management, etc). I realize that the J2EE landscape was
drowning in complexity and was pretty dismal in 2005, but this guy doesn't
understand the issues involved in developing web applications.

First, to suggest that individual libraries can provide re-usable high level
web application code is completely ludicrous. It can't work for so many
reasons:

* All those libraries will have to interact, and the interface between them will be complex. If they do work together they will end up being tightly coupled and before you know it you have a framework.

* High level functionality that includes data models, persistence, and presentation layers is not generic enough to effectively be a library. The complexity and configuration would quickly balloon out of control before it met even the requirements of 5% of web applications.

* Such libraries would end up being far more constricting than a traditional framework. A good example is Drupal, which is a very powerful framework/CMS with an impressive hook system, and an extremely high code to functionality ratio. Anything you might want to do with a website can probably be done in Drupal using a combination of existing modules, and you can write additional modules that access almost any part of the system and modify its behavior. The problem is that fine-tuning of the interface or certain kinds of customizations become very difficult under the crushing weight of the underlying assumptions that Drupal makes to enable it's magnificent generic-ness. The result is that all the various sites made with Drupal end up feeling very Drupal-y and there's a disincentive to really design your UI from the ground up and create a very optimized application.

What J2EE has blinded the author to is the fact that web frameworks exist to
solve the most common problems that come up over and over again in web
development. He needs to go write a few PHP applications to get a feel for the
issues, then try something lighter-weight like Django or Rails that confronts
those issues directly and then basically gets out of the way. In the first
half of the decade it was hard to find a good lightweight framework because
people were still wrapping their heads around the actual issues that needed to
be solved. Nowadays, not so much.

------
tolmasky
This is about as ridiculous as trying out one bad programming language and
then writing an article titled "Why I Hate Programming Languages". Clearly the
author has a problem with one particularly bad set of frameworks he's dealing
with now, and one set of framework-making mentalities. Yes, there are bad
frameworks. There are good frameworks too. I don't imagine anyone draws their
own buttons on the screen anymore. To continue the discussion in any general
format is useless, since there are countless examples of bad frameworks and
countless counter-examples of good frameworks. A more compelling discussion
would be one on what makes certain frameworks useful rather than trying to
place a final value judgement on the idea entirely.

------
edw519
Here's the dirty little secret that no one wants to talk about...

The purpose of "assisters" like frameworks and higher level languages is NOT
to make good progammers more efficient.

It's to make mediocre programmers more likely to produce _something_ of value
and to make poor programmers capable of producing anything at all.

And if the bell curve tells us anything at all, it's that these "tools" target
90% of all programmers.

But think about it, my fellow top 10% (lol), do you really need all this
stuff? If you're working alone or on a small team with a clear objective,
haven't you always had everything you needed with low level tools? If you need
any higher level tools or reuseable components, haven't you already been
building these all along?

Sure it's fun to play with new things and learn from others, but when it comes
time to really produce, don't we all know how to (and need to) roll with what
we know?

The need for frameworks and high level languages only becomes apparent when we
grow so large that we _can't_ find enough senior hackers. Only when you dip
down into the mediocre masses do you need this help.

~~~
snorkel
I agree completely. Web frameworks add a layer of code bureaucracy that really
doesn't need to be there in most cases. Reading and setting browser cookies is
not that hard. Creating and reading web forms and validating inputs is not
hard. Creating a relational database schema and objects that store themselves
in that schema is not hard. You can do all of this directly in mod_python,
essentialy by buildng your own framework, so you really don't need Django (I'm
know, I'm a heretic for saying so) But doing all of these things directly
mod_python takes time to learn how to do it reliably and efficiently. So I
understand Django's appeal to people who picked up a Python book and asked
"How do I create an event calendar web site in five mouse clicks?" and didn't
see a direct answer to that question so they went with a framework. Personally
I'd rather not toil under the tyranny of someone else's framework, especially
when they suggest you need to create Factory for a Consumer then connect it to
an Active Bridge connector... no thanks, I'll just use "mod_python import
Cookie" instead.

~~~
DanHulton
"essentially by building your own framework"

Why build your own framework when there's one already there? Already well-
used, well-tested, well-extended?

Sure it may be easy enough to do, but is it really worth it?

I, for one, would much prefer to be spending my coding time writing
application logic than Yet Another Validation Library.

~~~
axod
Because frameworks aren't optimized to your use case.

~~~
DanHulton
Hell, programming languages (typically) aren't optimized to your use case. You
modify them to make them so.

Good frameworks are the same way. I've already extended the hell out of Kohana
to make it more useful to me. This is work I would have had to have done if I
weren't using it, sure, but all the basic stuff is there all the same.

~~~
axod
Sure, it just depends. Quite often, I've found that modifying someone elses
code takes orders of magnitude longer, than just writing it yourself.

~~~
dusklight
the difficulty of modifying somebody else's code is proportional to your own
programming skill.

~~~
axod
Yeah I'm not sure that's actually true :)

Would you rather build a porche, or try to convert a clapped out old volvo
into a porche?

Tidying up rubbish, bad architecture choices, stupid coupling etc isn't fun.
It's twice the work - fixing all the stuff they did stupidly, and then
implementing it how it should be done.

------
jaytee_clone
I feel the analogue here is a bit off.

I'd say a framework is more like a factory that produces a variety of fixed-
size spice racks (among with other products). You have to learn what button to
press to get the right ones, and the spice racks produced will never be
exactly how you want them to be.

If you want to quickly generate lots of generic spice rack, then a spice rack
factory is all you need. But if you want something really outstanding and
unique, then a factory may be anti-productive, and you are better off building
it with your own hands.

------
lallysingh
I've seen good frameworks (OWL, Nitrogen + Powerplant, maybe 1 or 2 more), and
I've seen a crap-ton of bad frameworks (any web framework on java, minus
_maybe_ WebObjects).

They're necessary, but they're hard to do right. The man who did Powerplant
said he went through about a dozen different designs before getting one he
liked. That's why it was often so useful. Most times, people say "hey, let's
take these APIs and let people subclass! yay!"

And that's how you end up with crap like doGet(), doPost(), etc.

~~~
jimbokun
"minus maybe WebObjects"

What made WO great were the tools. There was still complexity there, but
WOBuilder and EOModeler made the whole process very productive. You could
think of your data model, your interface, and your business logic
independently of each other, and then use the tools to hook them together in a
way that made sense. Because of the way the tools were designed, they actually
made using good design for your application easier than using bad design.

That's the main thing missing from all the frameworks I see today, integrated
tools that automate the tedious parts and encourage good design practices.

To me, the WO tools go on the heap with the Lisp Machine, the Xerox Park
Smalltalk environment and HyperCard, as old development technologies that are
still ahead of today's state of the art.

EDIT: spelling correction

~~~
gnaritas
That would be _Smalltalk_ not _SmallTalk_ , and some of us still use it,
daily, for web apps. It might not be in wide use, but it isn't on the scrap
heap.

~~~
boucher
People still use WebObjects everyday too (I used to be one of them), but not
very many. I'd say WebObjects is basically on the scrap heap.

------
rantfoil
Was anyone else put off by "And, if you want to kill your ex-girlfriend,
there's really no substitute for a ball-peen hammer"?

I get it's a joke, but violence against women, when used in a semi-
professional context in a community of software engineers is one of those
things that keeps more women out of the field in the long run.

I'm not trying to be PC intentionally -- it just struck a raw nerve for me.

~~~
axod
That's just.... ridiculous. The main thing that keeps women out of the
industry is the fact they don't want to be in the industry and for you to
suggest otherwise, is sexist.

