Why I Hate Frameworks (2005)

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.

This was posted 47 days ago : 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.

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.

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

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.

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.

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.

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.

The complaint is actually about a design pattern for configuring a framework, popular in Java.

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.

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.

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.

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.

what's with all the jokes about killing women?

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.