I believe it is the natural tendency for our projects to end up with their own framework. I mean, our whole job is to automate and save time for others. So it is only natural that we see repeated patterns in our code and then also try to do that for ourselves as well. In the small we call it DRY and in the large, I suppose, frameworks.
The real danger in frameworks though is that they are coupled to everything. Later, something new comes up which the framework doesn't handle. Then like any piece of coupled code, changing the framework can cause rippling breakage throughout the code base. It's why on a deployed project we don't simply upgrade to the latest version of external frameworks when they come out -- to reap any new benefit usually requires first fixing breaking changes. So the upgrade has to be evaluated and planned out. And sometimes the choice may be not to upgrade because there is too much work (based on how dependent you are on the framework).
Don't get me wrong. There is definitely a positive value proposition to be had in centrally handling common plumbing and providing extensibility points for adding new features / capabilities. However, I found once I decided to formalize it into an (ostensibly reusable) abstraction, that's when the trouble began. You end up running into case after case where you either: a) make an opinionated choice that limits the consumer's options b) parameterize a choice which makes your framework more complex to use.
Frankly any app frameworks I made even when I tried to abstract them for reuse, I always felt they were lacking in some way. And in any new project I would start over from scratch and try to "do it right this time". Nowadays I do functionally the same thing, but this time without the pretense of making it reusable across projects. Instead, I reuse the relevant capabilities (sections of code or libraries) in different mixes across apps, as opposed to plugging into a grand abstraction. I believe this might be characterized as what Dan North calls the ginger cake pattern.
a) make an opinionated choice that limits the consumer's options b) parameterize a choice which make your framework more complex to use.
Interesting - that makes a lot of sense. This is good to keep in mind - I think I'm going to continue with this present tack, but within the context solely of creating this working application first before I start thinking about what this proto-framework might need to provide in a more general setting.
It's like Neil said, "It's very hard for a general-purpose framework to happen to provide the best solution for your specific problem domain."
Thanks for your perspective! Looking forward to watching this talk.
Oh absolutely, pursue that spark of interest. I will say that the ones I made were valuable learning experiences. Often in the "what not to do" kinda way, but still valuable. :)
I enjoy your thoughtful questions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I believe it is the natural tendency for our projects to end up with their own framework. I mean, our whole job is to automate and save time for others. So it is only natural that we see repeated patterns in our code and then also try to do that for ourselves as well. In the small we call it DRY and in the large, I suppose, frameworks.
The real danger in frameworks though is that they are coupled to everything. Later, something new comes up which the framework doesn't handle. Then like any piece of coupled code, changing the framework can cause rippling breakage throughout the code base. It's why on a deployed project we don't simply upgrade to the latest version of external frameworks when they come out -- to reap any new benefit usually requires first fixing breaking changes. So the upgrade has to be evaluated and planned out. And sometimes the choice may be not to upgrade because there is too much work (based on how dependent you are on the framework).
Don't get me wrong. There is definitely a positive value proposition to be had in centrally handling common plumbing and providing extensibility points for adding new features / capabilities. However, I found once I decided to formalize it into an (ostensibly reusable) abstraction, that's when the trouble began. You end up running into case after case where you either: a) make an opinionated choice that limits the consumer's options b) parameterize a choice which makes your framework more complex to use.
Frankly any app frameworks I made even when I tried to abstract them for reuse, I always felt they were lacking in some way. And in any new project I would start over from scratch and try to "do it right this time". Nowadays I do functionally the same thing, but this time without the pretense of making it reusable across projects. Instead, I reuse the relevant capabilities (sections of code or libraries) in different mixes across apps, as opposed to plugging into a grand abstraction. I believe this might be characterized as what Dan North calls the ginger cake pattern.
Interesting - that makes a lot of sense. This is good to keep in mind - I think I'm going to continue with this present tack, but within the context solely of creating this working application first before I start thinking about what this proto-framework might need to provide in a more general setting.
It's like Neil said, "It's very hard for a general-purpose framework to happen to provide the best solution for your specific problem domain."
Thanks for your perspective! Looking forward to watching this talk.
Oh absolutely, pursue that spark of interest. I will say that the ones I made were valuable learning experiences. Often in the "what not to do" kinda way, but still valuable. :)
I enjoy your thoughtful questions.