Ah frameworks, the evergreen topic of many a blog and podcast. It seems that every so often I encounter a strong anti-framework stance, be it CSS, JS, PHP, Ruby, etc. etc. The bottom line is: Using a framework creates technical debt. A framework can and will present design and implementation issues. Over the life of a project, workarounds in an attempt to solve issues eventually start to stack up and create new issues until you have a giant mess.
When I hear about frameworks and technical debt, the argument is usually that the developer is inheriting all the problems. Why not build their own version custom for the specific project? This is always well intentioned and the people I hear make this argument are almost exclusively the engineers that could make their own framework. It is also almost exclusively the wrong decision to make, especially for our clients and their respective budgets and timelines.
The argument for making your own framework assumes that you understand the problems correctly. I would argue that a “problem” is most often a lack of understanding, or a difference in opinion between the framework developer and web developer. These are not actual bugs, though they are often approached as bugs by the web developer. They feel that they know enough about the problem area to do it better. Or at the very least, they can spend a lot of time learning before design and build. Most frequently, custom frameworks created for a project end up being fatter, buggier and less capable than a common community solution. This wastes client money and turns out inferior projects.
I believe community supported and broadly used frameworks create tremendous value for our clients. When we use Laravel, Bootstrap or Foundation, we gain more testing cycles than if we hand rolled everything. Moreover, the biggest value in a framework is the feedback from a broad community of developer users. I don’t know that there is a framework problem big enough that putting ten dev-heads together won’t solve it.
Using a framework allows us to solve the right problem. This is where the framework debate starts and ends when it comes to choosing a technology stack for each project. We love our clients. They enable us to do work we love, and we feel responsible for making the best decisions possible to meet their goals. That always comes down to solving the right problem. Even if their application scale is big enough, their timeline aggressive enough and the specification large enough, will there be more value in creating a custom framework? Not when an existing one will give you more iterations, cleaner features and overall better code.
