The problem with frameworks at the time this piece was written (to be clear, I think they've gotten somewhat better since) is that the abstractions they provided were so horrendously leaky that you ended up writing more code, not less, because you need to do things that the framework was never meant to do, or was supposed to do but was bad at.

This has been my experience anyway. Even recently, I've had this kind of problem (not to name any names, but socket.io), but only because what I'm working on is somewhat more specialized than in the past.

I'm absolutely not trying to contradict you here. In general I agree with pretty much everything you've said. However you raise something that makes me wish to address the muddiness of the details.

> Using a smaller technology stack makes for an easier learning curve, but your day job after learning the basics involves ten times as much code ( == ten times as many opportunities for bugs...

I think you're implying here that not having written the framework abstractions yourself or in-house will reduce bug count. First, to be a bit pedantic, the opportunities for bugs is roughly the same over a given feature set between coded-with-framework and written-from-scratch. The the number of discovered and undiscovered outstanding bugs over that same feature set may be lower, but this doesn't necessarily reduce risk.

By using a framework you're making the assumption that most major bugs have been found and fixed by the sheer volume of people testing the framework in the wild. In a general sense, this is often a valid assumption. However this is in no way a guarantee of good testing coverage.

In my day job we decided to make further use of an open source tool to satisfy a particular security requirement. The tool in question has a community of nearly ten thousand users. However, it turns out that the advertised feature we wished to use was never really adopted by anyone in the community. Because of this we found a major "barrier to entry" type bug that had been outstanding for close to four years, and we lost nearly a month before deciding to scrap the effort and use something else.

Beyond bug count, it's been my experience that when framework bugs do crop up they're more likely to be very costly or time consuming. I say this for a few reasons. First, let's make two fairly reasonable (I hope) assumptions:

Assumption #1: Most people use frameworks to avoid having to worry about the details for which the framework offers a solution. This usually is the main value proposition of a framework (and the quote above alludes to this). This means that when you plan and design your software, you typically assume that the framework is correct. Most people don't budget time/expense for learning the framework's internals.

Assumption #2: If the framework is battle-hardened, most of the bugs you'll probably find are in oddball edge cases and/or are very difficult to track down.

In the best scenario your framework code is open and you can fix the bug yourself if need be. However you pay for this this with the original perceived value of the framework (no need to be an expert in its inner workings), and a lot of unbudgeted time. And let's face it; when we're in a time crunch, we don't do our best work. The probability of introducing new bugs when this occurs is quite high.

Aside from the specific application details that you're now worrying about, you now have new unplanned-for operational overhead. How do you maintain the change to correct the bug? You'll either need to figure out the correct procedures/coding style/etc to submit a patch/pull-request, or you'll need to maintain your own fork of the framework.

Or in the other case where you're working with a closed-source product you're just up a creek. Oh you paid for support? Isn't that cute...

I don't say any of this to attack frameworks. I use them myself quite often. However I do say this to attack the idea that frameworks make it safe for developers to remain ignorant to the inner workings of their system, regardless of which parts were designed/built in-house, as the fact that something is made and supported by a third party, commercial or community, has no bearing on its quality alone.

The problem (as I see it) is that when you learn a framework you're learning another person's vocabulary for talking about a category of problems. This is very useful when you're just starting out, but becomes problematic later on as you start to do more complex tasks that weren't necessarily well understood by the framework author(s).

The issue I have with frameworks is that the Factories tend to be too tightly coupled to the problems that the original dev or dev team saw, and they aren't flexible enough for me to re-imagine their purpose. They are a perfectly abstracted a solution to a concrete problem, and implementing their [collection|object pool|routing] "API" will only let you change the steps in the process that they thought needed changing.

Factories are a fixed-arity solution to an infinite arity problem. I can't recompose factories like I can functions (in a language with first class functions). Not to mention that the APIs created to marshal data between the objects created by these factories tend to be poorly thought out because, let's face it, we're all monkeys banging out code and none of us can think at the proper level of abstraction to consider everything. But instead of using simple data types and "assume-nothing" interfaces, they try to create an abstract interface with a sample size of one problem. That's never going to work.

Enterprise Frameworks typically say factory when they mean "configuration". And when they say pluggable there should be a footnote that says *with any of our handful of implementations, don't try to write one yourself. They're very good training wheels, but they aren't the panacea to everyone's problems. Use them when they make things easier, ditch them when they get in the way. Fix them when you have the time ;-)

No, I think he had it right. There's "enterprise" and then there's logically abstracted away in a meaningful and helpful manner. One is not the other. There's far too many bits of code I've come across with FactoryFactoryProxy with a single method that also produce a single FactoryProxy type which produce a single object type. That's not helpful, that's retarded. And when abstractions pile up, the details get lost in the abstraction noise. It's a delicate balance but one that has to be weighed depending on the needs of the developers.