| I think that the decision on whether to use a framework is very hard. When using a framework, you get most of the benefits right away, and most of the costs happen much later, when abandoning the framework is costly. Besides pure technical quality, you have to consider more murky issues: who wrote the framework? how long will they be around for? Does their problem match your problem? Will your interests remain aligned in the future? Is there a succession plan? Will new hires be familiar with it? What's the learning curve? Does it integrate with the other N tools you are using? Ideally, the decision to use the framework or not should be made by someone who has used it before. This is often not the case. My personal preference is to always use simplest tools that get the job done. I wish that hiring technical writers to write docs was more common. Most of the new libraries I have to use have documentation that is so poor, I have to use stack overflow + write test cases. Currently, I am in the middle of taking over a go code hairball from someone who left, and who loved external dependencies. Out of 31 direct dependencies, 11 are not at release 1.0 yet. Many have poor documentation. I believe that when I am done with it, our code will have fewer dependencies, and be half the size. |