I'm not a huge fan of these pieces that don't speak to why frameworks are created in the first place.
The counter point to this is that the purpose of frameworks is to turn O(N) problems into O(k) problems by implementing a seam in the code.
The problem a framework ultimately solves is that some teams will choose to use screws, some will use a hammer and nails, some will use a nail gun, some will use glue, some will carve connecting joints, some will use metal and weld, some will take a large piece of material and carve it out, etc. etc. and now you have 50 different ways to perform one task, which is to get the end result of joining two objects.
That means 50 different on-boarding processes, and 50 different design paradigms to manage, 50 different classes of corner cases, 50 different monitoring/operational paradigms, 50 different hiring processes, etc. etc.
Sometime between 50-500 engineers it becomes necessary to properly framework-ize the unit of business logic that product developers work on, like a route, to prevent operational overload.
Related: "Write libraries, not frameworks," which goes more into depth about how frameworks establish precisely such a "seam" and the responsibilities it entails.
> Frameworks' key trait is that they impose limitations on the programmer. Rather than providing a set of new things the programmer can do, they establish a boundary on the things the programmer can do.
Simply stated and very insightful.
This is a way better article than the posted one.
Another way of thinking about this is that a framework is a regulating authority on a tragedy of the commons. The commons in the case of software is complexity. Too much complexity becomes impossible to manage and grinds development to a halt.
Not sure it's always the key trait. In software frameworks are so often accompanied by a rich library of packages or code that folks may consider another important trait is their baseline of functionality.
Some frameworks are "batteries included" while others are a "bag of reusable components".
Ah, but that is exactly where the carpenter analogy truly works - a good carpenter understands the strengths and weaknesses of all those techniques, and when to apply each. Just like a good software dev understands when to apply frameworks and libraries, and knows enough about each to choose the right ones. (And yes, which ones just aren't quite ever the right answer.)
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.
The counter point to this is that the purpose of frameworks is to turn O(N) problems into O(k) problems by implementing a seam in the code.
The problem a framework ultimately solves is that some teams will choose to use screws, some will use a hammer and nails, some will use a nail gun, some will use glue, some will carve connecting joints, some will use metal and weld, some will take a large piece of material and carve it out, etc. etc. and now you have 50 different ways to perform one task, which is to get the end result of joining two objects.
That means 50 different on-boarding processes, and 50 different design paradigms to manage, 50 different classes of corner cases, 50 different monitoring/operational paradigms, 50 different hiring processes, etc. etc.
Sometime between 50-500 engineers it becomes necessary to properly framework-ize the unit of business logic that product developers work on, like a route, to prevent operational overload.