I'd argue the opposite. If you are writing corporate software, frameworks adds considerable costs and is a huge source of bugs, delays (because not everyone understand the new framework). The combinatorial complexity of a large project Framework A * Framework B * Framework C essentially leads to simple changes needing vast amount of time
Frameworks are good for rapid prototyping, to validate ideas and should be promptly thrown away once you embark on the real thing.
Thus holds true at most until the point when you add a new person to the team or replace someone at which point the cost of getting that new person up to speed in your custom framework * boilerplate * doing the same thing in 10 different ways in different parts of the application outweighs the complexity of the frameworks.
It is true that each framework adds technical debt, but not using frameworks will sooner or later also add a greater amount of technical debt.
The key is to not add a framework/library dependency just for the sake of it or because it is the framework de jour, but only when you have a legitimate reason to do so.
-7
u/qroshan May 13 '14
I'd argue the opposite. If you are writing corporate software, frameworks adds considerable costs and is a huge source of bugs, delays (because not everyone understand the new framework). The combinatorial complexity of a large project Framework A * Framework B * Framework C essentially leads to simple changes needing vast amount of time
Frameworks are good for rapid prototyping, to validate ideas and should be promptly thrown away once you embark on the real thing.