4 ms·

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 bu

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 13y ago
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.
foobarbazqux 13y ago
It's also possible to have a large and clean non-spaghetti codebase that does not rely on some framework, be it pre-existing or ad-hoc. For example, Linux.
megrimlock 13y ago
"Framework" for some has the connotation of being dogmatically prescriptive: a monolithic culture of libraries where you must buy into the whole system to use any of it. For example, a classical C++ framework might come with its own string class, its own container classes, its own smart pointers, its own way of binding to other languages, etc. Escaping the cultural ecosystem to integrate something external can be quite a burden. A middle ground is where you try to factor out useful parts but do so in a way that keeps in mind that users might not want to also use associated packages X, Y, and Z. This means backing off a bit from the maximally elegant integration you might do when you have a giant framework ecosystem and imagine people wanting to use all of it in its glory. Doing this requires resisting the inclination to build a code empire -- a megalomania that anyone ambitious among us has felt as your excitement at being able to build more complex things grows. You only learn the opposite instinct after being burned suitably by frameworks, or looking upon your own empire and despairing.
davvolun 13y ago
In my opinion, the biggest problem with an "ad-hoc" framework, or custom-built framework, is that there is definitely going to be less documentation for the next person on how to use that framework.

CamperBob2 13y ago

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.

foobarbazqux 13y ago

It's also possible to have a large and clean non-spaghetti codebase that does not rely on some framework, be it pre-existing or ad-hoc. For example, Linux.

megrimlock 13y ago

"Framework" for some has the connotation of being dogmatically prescriptive: a monolithic culture of libraries where you must buy into the whole system to use any of it. For example, a classical C++ framework might come with its own string class, its own container classes, its own smart pointers, its own way of binding to other languages, etc. Escaping the cultural ecosystem to integrate something external can be quite a burden. A middle ground is where you try to factor out useful parts but do so in a way that keeps in mind that users might not want to also use associated packages X, Y, and Z. This means backing off a bit from the maximally elegant integration you might do when you have a giant framework ecosystem and imagine people wanting to use all of it in its glory. Doing this requires resisting the inclination to build a code empire -- a megalomania that anyone ambitious among us has felt as your excitement at being able to build more complex things grows. You only learn the opposite instinct after being burned suitably by frameworks, or looking upon your own empire and despairing.

davvolun 13y ago

In my opinion, the biggest problem with an "ad-hoc" framework, or custom-built framework, is that there is definitely going to be less documentation for the next person on how to use that framework.