
Why I Hate Frameworks (2005) - ksrm
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12&
======
plorkyeran
My experience has been that for systems of nontrivial size, the two
alternatives to using a pre-existing framework are spaghetti code and an ad-
hoc framework built as you go. The first is obviously bad, but the second is
wildly variable. Sometimes you end up with a nice lean framework that's a
delight to use and solves the problems you need to solve and not much more.
Sometimes it turns out that you actually did need a heavyweight framework, and
your nice lean framework gradually turns into a worse version of things that
already exist. Sometimes the core design of the ad-hoc framework turns out to
just be a terrible idea from the beginning.

~~~
CamperBob2
Also, and this is the part that's always bugged me: you will never know if
your homebrew framework is a great one or an awful one until it is way too
late to replace it.

It must be a corollary to the Dunning-Kruger Effect or Peter Principle: you
can't know your own competence.

------
baby
This was posted 47 days ago :
[https://news.ycombinator.com/item?id=6283601](https://news.ycombinator.com/item?id=6283601)

I'm not again repost but I don't think the situation has changed in less than
2 months.

~~~
ksrm
Ah, I didn't realise it had any comments. Apologies.

~~~
pak
No, thank you. And this is coming from someone that read the OP years ago. The
fact that short-term reposts gain so much volume on here indicates that front
paging is incredibly stochastic. It's been this way for a while; submit a link
once and it gets 0 comments, and the second time 130 comments, and the third
14 comments, all within a month and using the same title. As sad it is, the
only way to fight through a stochastic system is to increase the frequency of
posting everything so that on the average things break through for the "right"
amount of time. Though, this doesn't bode well for the future of this medium.

------
drakaal
At our shop we don't use frame works, well at least none that came from anyone
else.

The problem with frame works is that if you need to modify them, then you no
longer can just update them when everyone else does. You are stuck always
making changes to the framework ever after as they new ones come out.

But also you don't often fully know what the code does. If you have code that
does something you don't understand then you end up not understanding how it
changed later.

With Front End Development things like TwitterBootStrap get you a great
looking site very quickly, that is nice. But if you want to tweak things
suddenly your version isn't going to be the same as the stock version and you
can't have it be cached from some fast CDN, and so your site is slower than it
should be.

With BackEnd small changes to the official version of a framework can
introduce bugs. Sure this is also true of things like Minor Revs to the
language. (A lot of people got burned by moving to PHP 5.4 before WordPress
was ready for it, and had only decided to enable auto updates to PHP because
WordPress 3.2 required PHP 5.1) (And I'm not fond of PHP or WordPress so don't
flame me because this is my example, it was one of many, but one that a great
many people experienced so I figured the enormity of the event made it a good
example)

The moral of the story is OWN YOUR CODE. The more you rely on other people's
code the less you are the master of your own fate.

~~~
gonnakillme
You'd rather maintain a complete homespun project than maintain a fork of an
existing one?

~~~
VLM
Need to include a qualifier that they're identical size/complexity. I find it
hard to believe an app exists for a serious "bulky" framework that uses
99.999% of the code in the framework. Once you get down to 0.1% or so it
starts getting easier to maintain your own ten lines than to
cooperate/tolerate someone elses 10K lines.

------
norswap
Looks more like a rant about factories than framework.

I define a framework by opposition to a library. Your code calls the library,
but the framework calls your code (the "hollywood principle": we'll call you).

I actually dislike frameworks because it's really hard to see what's going on
behind the scene (relevant stuff).

------
yason
Frameworks happen when you've written your nontrivially big program, you've
successfully abstracted out all of the mechanisms in effect in that program,
and actually rebuilt your original spaghetti mess on top of those
abstractions, everything is working nicely, you've carved out most of the
cruft you at this point know you won't need, and then you get the killer idea
that _the next time_ you—or someone else!—need to write a similar program it
will be much less work if you turn your existing program into a framework for
writing similar programs.

Nobody ever does and you never do.

And if you did, you'd be several steps ahead of yourself at that point and you
would do it all very differently because you know more now.

Frameworks are just reflections of a single program: a framework is
essentially extrapolating from one data point.

Simple modules or interfaces can be turned into genuinely reusable libraries.
They'll become orthogonal tools that can be used with other libraries, and
often without any of the libraries it was developed with. A big software
project always contains several libraries originally written for the project.
But what you think is a framework of code that contains several modules or
libraries for doing XYZ-ely things and that is used to implement program XYZ
is actually the program XYZ itself.

------
nickthemagicman
The main thing I like about frameworks is the standardization.

Frameworks usually force you into doing things a certain way, with a certain
directory structure, with very specific api's.

And if some one walks on knowing that framework they can get up to speed
pretty quickly.

And if YOU go back and look at the project months or years later you can get
up to speed quickly.

Also it typically keeps the code really neat.

Considering Java is typically years behind PHP in framework technology, I can
imagine the authors frustration though.

------
gmjosack
When I first started programming I used to quote this post. A bit later on I
realized I was making excuses for my Not Invented Here Syndrome. Now I favor
getting things done, though my NIH Syndrome still peaks out every now and
then.

~~~
babs474
The clojure community has great meme: libraries over frameworks.

In my mind java is notorious for having frameworks that box you in. You have
to think like the framework or you will have major problems. Think
spring/hibernate.

The library over framework idea is that external tools that you use should
solve a problem and be composable. You should be able to mix and match easily
if you want to throw something away or introduce something new.

Composable libraries can reduce NIH and keep you flexible.

~~~
blt
Choosing to use a library should still be a carefully weighed decision. You
often must commit to the library's data structures, or write a bunch of
boilerplate wrapper code to insulate them from the rest of the system. I
imagine this is less of a problem in languages with dynamic typing or golang-
style interfaces.

If you're using only one or two functions from a big library, it might not be
worth the overhead. A lot of Boost libraries are super complicated and really
turn me off when I want something simple like a directory scan or a
synchronous socket. Sadly there is often no alternative because the C++
community has thrown so much weight behind Boost.

I wish C++ had a module/package system and a simple version of Boost that only
covers the most common 90% of functionality. But that leads to another problem
with libraries: when you suddenly hit the limits and need to completely ditch
them for something more powerful.

I like libraries but it's not always an easy choice to use one.

------
alok-g
The article shows problems with each approach, without hinting to a solution.
I do not see what is wrong with the shop selling a bunch of different types of
hammers, while providing guidance on when to use which.

I am also not sure if the complaint is against the specific frameworks OP has
seen, or he could really show that this would apply to all frameworks
including those not built yet. My guess is the former.

------
dgreensp
The complaint is actually about a design pattern for _configuring_ a
framework, popular in Java.

------
jmcdonald-ut
We should always remember to not think in black and white.

My first complaint to the article is that it paints a framework as a universal
hammer that tries to do many things. This simply isn't a fair comparison. I am
not a builder, so I'm sorry if this analogy falls flat, but it's less like a
universal hammer and more like the framing of a house. While there might be
different approaches of framing a house for the most part the goal of framing
is to ensure the house is structurally stable and can then be built into what
the owner wanted. This is exactly what a framework attempts to do. My second
complaint is similar.

If I'm building a simple "spice rack" such as a contact form then a framework
is certainly overkill. However if one uses a framework to solve such a simple
solution then the complaint should be targeted towards the developer. Quite
frankly given the hardware available, and the fact that I could develop
something like this quickly with or without a framework, it almost makes this
point moot.

Finally it's the job of engineers/developers to understand that each problem
has multiple solutions. As such it is up to the engineer to choose the
solution that best fits the problem and execute. Frameworks will not always be
a good solution, but at times they will be absolutely the best decision one
can make. Good engineers don't think such black and white terms.

------
iSnow
I think what he is really targeting is enterprisey enterprise frameworks that
are checklist compliant. Those have every feature you want, even if they
support it only half-heartedly.

And because they try to be everything to everyone, they suck.

Truth is, for a medium to large system, you either use a framework or you
write something that approaches a framework or you have a complete mess on
your hands.

Targeted frameworks that solve real problems (like Angular.js) are simply
great. Bloated messes like JEE are not so great.

------
contactdick
I don't think an analogy about hammers is a particularly strong way to make a
case for or against software frameworks. There are many situations where a
framework makes a lot of sense and lots of situations where they don't. Some
simple heuristics like ' you don't want to use a framework when your project
has the following properties... ' would explain the case better and also help
create discourse rather than black and white opinionating.

------
Systemic33
He clearly has no idea what problem a framework solves.

Framework is exactly designed so you don't have to build an entire factory
yourself, you let other people do that, and you can concentrate on the
specific challenges for your problem. In my eyes, a framework is the good old
hammer approach. See frameworks like the different kinds of hammers. Different
hammers for different jobs, just like a different framework for different
jobs.

------
johnbirch
what's with all the jokes about killing women?

------
static_typed
Frameworks sound great until you inherit a franken-app built using one. You
might be able to understand bits if they religiously followed the dogmatic
usage of the framework but more likely they just wanted to get stuff built and
not wanting to learn someone else's idea of the perfect wheel maker framework
and so ended up still building something unique, baroque, and possibly
impenetrable.

Frameworks in the most case feel like straightjackets, so I understand why
developers feel the need to abandon some of the magic and build bits that are
actually simple robust and supportable, but it can become hell for subsequent
developers.

~~~
pjmlp
My first framework was actually in Turbo Pascal (Turbo Vision).

Since then I have used:

\- Turbo Vision - C++ as well

\- Object Windows Library in Turbo Pascal and C++

\- Microsoft Foundation Classes in C++

\- An in-house framework done in TCL and C

\- An in-house framework done in C

\- An in-house framework done in a mixture of Perl, C++ and CORBA

\- J2EE in Java

\- An in-house framework in Java for web development

\- ... (lost count of all remaining ones)

The desire for frameworks is something that runs deep with enterprise
architects.

How many corporations tend to have architects that take a nice framework and
always have to put their own layer on top of it as well.

~~~
Roboprog
I thought that OWL (at least the Pascal version) was pretty reasonable for
what it did.

I can understand the frustration with Java, though. The first time I started
reading through "web.xml", I thought it was a bit much. Then I read the EJB
specs...

Struts, at least the older versions I've had to maintain, is a nightmare. RoR
seemed to have a lot less BS to do the same thing.

~~~
pjmlp
Yeah, OWL was miles ahead of MFC.

