How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn
Sander talked about frameworks and the usual problems with them:
- How to choose the best framework from over 9’000?
- Some frameworks integrate only specific things (like logging or building a UI), others include everything and the kitchen sink. Which is better?
- How do you convince your management to buy a framework, train the developers, testers, support people for it?
- How do you get the other developers to agree to your choice?
After selecting a framework, the trouble starts:
- What do you do it an important feature is missing? Do you add it? How do you maintain it? Do you file a bug report? What if it’s being ignored?
- Half along the project, you find a framework that is better suited.
- How do you handle bugs in the framework?
- When do you upgrade after a new version comes out? What if the new version has dramatic changes that break a lot of your code?
- What if development of your favorite framework stops? Do you take over or walk away?
- If one framework isn’t enough, you’ll find that dependencies tend to kill you because all the problems above multiply.
- Sometimes, framework A has a hidden dependency on logging framework B but your company uses logging framework C.
The way to answer these questions:
- Know your architecture. What do you need where?
- Instead of using the framework directly, put in an abstraction layer that says what you want and does it using the features of the framework. If “something” happens, chances are you only have to change the abstraction layer.
- Use dependency injection to clean up your code from unwanted dependencies.
Dark Views 
[…] How frameworks can kill your projects and patterns to prevent you from getting killed – Sander… […]