Why I Hate Frameworks (2005)

Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in different programming languages just for a website (true story))

I mean who actually gets to decide what sort of approach to use, and what are their incentives?

The senior in the team is in charge of deciding what approach to use. The senior's (personal) objective is not to get fired, maintain their position as the most senior so they can get the payrises and promotions, etc. So they sort of have an incentive to choose something that is going to be easier to understand for them than for others e.g. juniors, a kind of "moat" to protect their position of power and high salary getting attacked by lower paid juniors who don't yet have the experience to understand complex abstractions over manual tasks they haven't yet done themselves.

I mean obviously that's not a kind thing for a senior to do, nor something that's in their employer's interest, but on the other hand it is rational given their incentives...

...and that's how the the factory factory factory also provides immediate safety and security benefits!

/s

Just looking at this listing, without looking at the comments in each one, this seems to have a sustained resonance.

Maybe I’m biased–it certainly resonates with me!

You're being called up because the problem is specialized.

Now as a carpenter, you go to the container store and then go back to your shop to dismantle prebuilt products and glue a bunch of different pieces from different containers together and present the Frankenstein cabinet as the product back to the customer. Also, you're on the hook for maintaining it.

Is it faster then just doing it yourself? Higher quality? Cheaper? Maybe...

Competency is the key skill here - someone could claim they're competent in both the NIH and framework way and they choose frameworks because of their vast power of assessments but statistically speaking, they're probably just choosing the frameworks because they lack the competency to DIY and are Dunning Krugering themselves.

A lot of this depends on the types of jobs you decide to take on. The boring ones are pretty easy to do with frameworks but the interesting ones are wildly unclear whether you're saving or wasting time by choosing one path over another especially if you're interested in the product's reliability and longevity.

The amalgamation of frameworks approach makes long term upgrading somewhere between very expensive and impossible. Dependencies, schemas, templating, test syntax can all change in totally incompatible ways as your version gets abandoned and you get locked in to whatever was hot 10 years ago. So much for security patches.

Eventually you'll end up forking the dependencies you once used to save you time and then patch them yourself - code ages way quicker with (most) frameworks.

In fact, if somebody didn’t use a common library or framework and instead “rolled their own” it’s downright irresponsible, obnoxiously egotistical and just creates a huge maintenance burden for whoever has to maintain it when you move on.

Take for example a crud app in ruby. If instead of using rails or another framework you instead “rolled your own” for one it would take you way longer for two it would never be as battle tested as the framework and lastly you are guaranteeing that whoever has to maintain it will need to learn the idiosyncrasies of your amazing implementation with zero outside help. It’s a recipe for disaster.

Sometimes, that quality/cost tradeoff is desirable, sometimes it's not. The trouble comes if using a factory or framework is the only, or even main, tool in your toolbox, and it ends up getting used for everything.

A framework you would use in order to pump out a ton of services quickly, just like a factory in this case. They'd be similar, with similar functionality and such, but you can produce them quickly and upgrade things across all of them fast. They wouldn't by optimal, but time from development to launch would be quicker.

But most startups and companies start with one web service, where at that point you don't really need a framework. What you need instead is careful deliberation and implementation, together with development speed and also enough proper architecture to continue to facilitate development speed in the future, but not too much as to over-engineer things. A balance if you will.

But unless your business/startup is about pumping out 100s of websites, a framework will hardly help you achieve your goal faster.

The same is true for code. Are you writing one application or are you writing the same application for many different customers? In one of those cases you would benefit from some sort of template but in the other case it all the extra stuff to scale just gets in the way.

If you want your one self-serving spice rack to scale then just plan ahead and make it bigger than your current needs so that you can add more spice later. Again, that also applies to code. If you want your one application to scale then just plan ahead. Jumping immediately into a framework only indicates you lack the confidence to make appropriate planning decisions.

The end product here is the food, after all.

When you go to cook a meal you’re oblivious to the framework of abstractions that go to make it possible for you to obtain and store and conveniently dispense your spices - as well you should be.

The pieces are mass produced, the assembly is done by humans. Because unlike software they are not insane.

There is no at scale for 99% of companies.

The break even point for a factory building spice racks buying machines instead of humans is an immense volume of spice racks - like 100+ spice racks an hour type thing. Maybe more.

Just like software, the number of companies that need to produce spice racks at this volume is miniscule. Unlike software, the ones dumb enough to buy machines they don't need go bankrupt very quickly.

I've worked in projects like this. In most cases, they contained what amounted to a part of a framework. The catch in the ones I worked on is that the authors had not realized they were building a framework and so did not think through their division of functionality, cross-cutting concerns like logging, and so on.

Inevitably, each of those had started as simple project. Over time, they had accreted one easy add-on after another. Eventually they're large, complex, and difficult to work on for anyone who didn't create them.

It's been my experience that most projects tend towards complexity over time. A well-chosen framework will require a bit of complexity up front to get going and provide a lot of options you can integrate as your needs grow. Preferably while letting you focus on the specific things you need that are different, rather than having to think about how you want to do logging and so on.

If all you need is HTTP routing, then Flask is great, but every time I tried to use it for the kinds of things Django is great at (databasing, templating, forms), I had to effectively roll my own crappy version of Django. (Something something every sufficiently large C++ program has a poorly implemented version of LISP embedded into it.)

I saw this dramatically demonstrated by an enormous Flask installation that would have greatly benefited from a little imposed structure. I bounced hard from that gig after being shown the code because it was going to be a massive pain to understand the poorly designed abstractions. But it wasn't even the maintainer's fault - it was pretty good code but it had only been designed by one person, both the abstractions and the business logic. And the abstractions were leaky simply because abstractions are difficult to design.

The framework allows you to completely offload the architectural decisions underneath the framework to many person-years worth of design, bug squashing, and security fixes. How do I add headers to a request? Django has one opinionated way. Where do I put my database models? models.py and if you put them there you don't have to do any connection fiddling.

The ideal of a framework is that if you release attachment to how things you don't actually care about anyway are done, you get thousands of free high quality lines of code.

I learned a lot from Sandi Metz about the costs of "The Wrong Abstraction" https://www.youtube.com/watch?v=8bZh5LMaSmE

For instance, you could have an http framework that handles things like compression, buffering, timeouts etc, which are likely to work everywhere. But you could also design it such that each mime type comes with a separate class, like a HTMLTreeBuilder, or something like that, which would be horrible and way too constrained.

Elaborate type systems can, in some cases, seduce this kind of overengineering. If it really looks like something can be modeled as a type, chances are that the author cannot resist it.

Rather I think it'd be better phrased as "frameworks should use simple abstractions and methods as often as possible", which the language naturally pushes people towards imo. I believe this causes most Go frameworks to be referred to as "microframeworks".

I'm not sure what made you think it's an "appropriate" framework, it's literally antipattern on antipattern and it's not even the worst thing, neither is the fact it's 10x slower than anything else out there - what's worst is the blatant lying, bunch of security issues and using it as an advertising platform to push subpar services onto devs stuck with it.

Oh, you want routing? "Not my business", says React. Go add a routing library. You want a framework for managing global state? Go find one. Want a kitchen sink frontend solution which bundles all of these commonplace features together? Use Create React App, or Next.js, or whatever fits your use case.

That's why I love React. The complexity of the solution matches the complexity of the problem.

Hello world:

    const App = () => <div>Hello world!</div>
    root.render(<App />);

    const App = () => <button onClick={console.log}></button>

    const OneTwoThree = () => [1, 2, 3].map(i => <li>{i}</li>)

    const App = () => (
      <ul>
        <OneTwoThree />
      </ul>
    )

    const App = () => {
      const [isGoogleUp, setIsGoogleUp] = useState(true);

      const checkGoogleStatus = () =>
        fetch('http://google.com')
          .then((response) => setIsGoogleUp(response.ok))
          .catch((err) => setIsgoogleUp(false));

      useEffect(() => {
        checkGoogleStatus();
      }, []);

      return isGoogleUp 
        ? (<span style={{ color: 'green' }}>Google is up!</span>)
        : (<span style={{ color: 'red' }}>Can't reach Google.</span>);
    };

https://www.brandons.me/blog/libraries-not-frameworks

Now, do we do that well? Clearly not. But that is the right place to collectively focus on improvement. We don't need to argue that frameworks or other solutions either should or should not be used, we need to focus on why they exist, what problems they solve, what problems they cause, and drive understanding of when to use each tool.

I think the difference isn't between the difficulty/complexity of that individual action but the overall complexity of everything up to that point. Once upon a time the simplest web tutorials might have involved "Open a text editor (already on your PC), write these 10 lines, save it in this directory on your web server or open the file in a browser". Now even the simplest tutorials have way more dependencies/prerequisites and often involve building projects, installing things, framework choices, etc

Once you're already setup and going it may not feel complicated but from the perspective of the dude just trying to buy a hammer it certainly looks complicated.

Although, frankly speaking, Java libraries are still the most convenient to include/extend than most other compiled languages I've seen so far. Probably because of that culture of over-engineering for abstraction/extensibility.

https://issues.apache.org/jira/browse/XMLRPC-147

Edit: I donno why, but the concept of dubious soup has me CRACKING UP right now.

I concur with this because programming with Clojure feels wonderful. Your code is a straight line from input to solution. With imperative languages, you see yourself applying the duct tape.

The thing I've seen the most in this industry is the opposite of that: teams that would mostly use third-party tools and frameworks, but the result was effectively the same, with complexity exploding and becoming so unbearable that the teams inflated to compensate, with productivity grinding to a halt. It happens with third-party tools as often as it does with NIH.

Like you say, Kafka, Kubernetes and Spark would add a higher-degree of complexity. They aren't really that simple to manage in real world production environments. That's the problem here: the complexity. It doesn't matter where it comes from, it will bite you in the ass.

One extreme of that is off-the-shelf enterprise software, that often requires a team of consultants to integrate. I've seen a few disaster, one software specifically started with a 500.000 price, but things became so complex the project ended up costing 4x that. There is no panacea against complexity. It costs money and takes time.

The main problem here seems to be the "questionably designed and lacks readily available support" part, which is something universally bad, even when using third-party software. You can design your infrastructure badly. You can make questionable design using third-party tools just as much as you can with your own code. And support is also very often not readily available.

"Similarly, if everyone agrees on using Kubernetes and Docker"

I'm totally sympathetic to things becoming standards, and I don't have an axe to grind with those two tools, but the reason for the pushback against tools like Kubernetes and Docker is grounded on reality. Not only they introduce complexity by themselves, they are often just band-aids for accidental complexity introduced by teams and by third-party things like programming languages and frameworks.

Don't have time now to find links of Jonathan Blow, George Hotz, Casey Muratori, and many other decidedly non-junior programmers complaining about the absurd, unnecessary complexity of modern software development.

The people who complain are the people who know how much simpler it can be.

Now, there is a separate phenomenon of green devs who think they can rebuild X only because they can't fathom the bulk beneath the iceberg's tip. That is real too. But it takes nothing away from the very real fact that the vast majority of software written today is much, much more complex than it needs to be.

Or the actual senior engineer, as opposed to the mid-level engineer with a senior title. It's the ones in the middle that really love adding in the complexity - you have to relearn how to prune it back out.

Vis-a-vis the conversation that has ensued from this statement, I'll offer the suggestion that the real seniors are the ones who don't make blanket statements one way or the other, and appreciate the distinction between incidental complexity and intrinsic complexity. Some times, the problem itself is simply complex and requires a complex solution. One should not rush to eschew complexity in those cases. Other times, the complexity is incidental and is brought in by the choices of the developers. In (many|most|all|??) of those cases, we should try hard to avoid that complexity.

20+ years later and I’m still saying this. Quite possible I’m still the junior in terms of skill though.

Yeah, this is true. But I often wonder how much of this is because the seniors have given up on simplicity and since they have internalized the complexity it doesn't bother them anymore.

Essential complexity is exactly that. The entire game is to separate it from the accidental complexity. My career/life was revolutionized by a paper that is 100% focused on this very topic:

https://curtclifton.net/papers/MoseleyMarks06a.pdf

The solution to eliminating accidental complexity is ultimately presented as a flavor of relational model, which I simply read as "please just use SQL for most things". This perspective has served me exceptionally well over the last ~4 years now.

A quote I like from Chapter 8:

> The relational model [Cod70] has — despite its origins — nothing intrinsically to do with databases. Rather it is an elegant approach to structuring data, a means for manipulating such data, and a mechanism for maintaining integrity and consistency of state. These features are applicable to state and data in any context.

Chapter 9 offers an actual proposed solution - Functional Relational Programming.

At the end of the day, suffering in a cesspit of complexity is a choice. The relational model is the answer for untangling highly-complex (aka high-dimensional) problem domains, especially ones that require arbitrary downstream views of the data. The central piece of magic with the relational model (as applied to the real world) is the query planner. You should start thinking of this as an actual code-writing super AI that can answer optimization questions 1000x faster than your best developers. All you have to do is give it a tiny pile of hints to work with, and almost any arbitrary request will be satisfied in a nearly-ideal amount of time.

- Everything's an object -> Let's define lots of nouns!

- Classes cannot be declared to implement interfaces after the fact -> Let's write some adapter classes!

- People get tired of writing adapter classes and notice that JVM has reflection capabilities -> Let's make a framework that generates adapter classes as needed!

- Everything's heap-allocated -> Let's avoid excess allocations by re-using objects! Which means you've got a big web of interlinked mutable thingamabobs floating around, made possible by Java's pretty-good GC.

- 'const'ness ('final'ness in Java-ese) is defined on the type, not on where it's used -> Most classes are written assuming mutability, and if you want immutability, you need to create an entirely separate type hierarchy.

I could go on.

When I want to write a Java program but keep it simple, I usually end up writing something that looks more like a C++ program. Minimal, domain-specific classes with as much setup in the constructor and as much `final` as I can get away with. But it's not as ergonomic a language for writing programs in that style as C++ is. And once a coworker brings in some library written in the conventional combinatoric-explosion-of-classes-and-pointers-to-mutable-objects-everywhere style, you're pretty much stuck with it.

I don't like React.

What happens when you need to disable nagles, avoid copies of the request body, use websockets, gRPC, etc? You’d need to pray that the framework gives you an escape hatch.