And if you rely on someone elses code which you don't understand, you won't even be able to fix the critical bug. At least you stand a chance with your own code.
Experience a couple "framework emergencies" then you'll hate them too. And I thought they were supposed to make things faster and easier, not the reverse.
Your homebrew framework is going to have to go through all the same growing pains as any other, but you won't have anyone to lean on when the going gets tough.
If it's an open-source framework you're using, you can always fork and fix or monkeypatch if you've got problems. Most of the time your issue will be patched already in a pull-request, it's just a case of applying it. Rarely do you have a situation so unique that nobody else has experienced it.
Except, of course, when you're using your own framework.
I've seen so many projects flame out in a spectacular way when developers get it in their head that they can write their own framework, or that they don't need a framework at all. That's the first step towards unmitigated disaster. The next step is to fall into a hole that you can't get out of without a whole lot of work, and have to solve a problem that those frameworks you should've used in the first place have already addressed.
Don't forget that code you understand today quickly turns into code you don't understand in the future. Don't think just because you wrote it you're automatically golden when it comes to making fixes.
And that is the fundamental mistargeting of most framework marketing. The ideal short demo or short tutorial for a framework is probably a noob-friendly simple "CRUD plus a little bit". On the other hand that is a horrible actual application for a framework, all that complexity for little reward. And its such a noob magnet. Never programmed in ruby before? No problemo, "rails new crud-demo" and good luck.
I'll agree you need a framework to do something complicated. Not everything is complicated, or grows to become complicated.
This may be the hidden meaning of the original article from 2005. Superficially the joke is frameworks are hyper abstracted into factories for factories for factories (well maybe yes, maybe no). But the more fundamental interpretation of the story is I don't want to enter mass production, I want a fast simple reliable one-off. It will never be the next twitter and it will never be used by more than 1000 people. And sometimes, that's OK.
It's a fine line and slippery slope to be sure. I think that after programming for many years though, a seasoned developer should have honed instincts as to what is probably an established pattern and what isn't. For me, the decision was made when I found I was wasting more time wrestling with the framework rather than just using it.
What framework were you having such a hard time with? Most you need to do it "their way" or you'll be going against the grain all the time.
I've spent a long time in Rails and it solves most Web + CRUD problems well enough. When it doesn't you have options.
Recently I've been doing more NodeJS stuff which requires a completely different mind-set. If you try and do Rails in NodeJS you will fail, and vice-versa. Same goes for something like Django.
This is why picking a framework that approximates your requirements and matches with your philosophy as closely as possible is essential.
Going without a framework is almost always a disaster. At the very least pick one that's thin enough it doesn't get in the way.
Yea that's just the thing. I don't build web apps. I was a backend developer and there are lot of things that have to happen on the backend that doesn't fit in the standard CRUD or MVC pattern.
I think you're overgeneralizing on the last point. I've shipped things without a framework that have been some of the most stable pieces of software I've written.
Not necessarily. I think I've fixed my lion's share of other people's code that I have embedded in my own systems. In fact, I've never been up on a Saturday night due to my own bugs. In the afternoon when I'm trying to fix my unit tests sure, but not Saturday at 1am.
In an isolated system, sure. Or extremely well defined fully enforced demarcation points in a large system, sure. However as part of a large business system, that can be completely out of your control.
Especially if there is a demarcation point or highly detailed definition, but multiple incompatible interpretations simultaneously exist.
If the concept of the failure mode doesn't even exist when the unit test is being written, or is in direct opposition to the stated business plan at that time so "it can't happen" then unit tests can't help.
Even worse is political issues. Yeah sure I promised in writing our demarc point is I'd send you an ASCII file but it changed at midnight to UTF-16 strings inside an XML file and you're either going to like it or work elsewhere and I can make this stick. Oh, well, when you put it that way, then I guess that's why I'm working at 1 AM. A contrived example for short simplicity, the real world is much longer and more complicated.
Experience a couple "framework emergencies" then you'll hate them too. And I thought they were supposed to make things faster and easier, not the reverse.