That's really great! I went to 'ThoughtWorks On The Beach' in Cologne, Germany, and there was this really nice idea to just print a dependency graph of your project to see if you can still grasp it or if it is getting out of hand.
True, but in general, the more code, the more bugs. Now there are a number of qualifications to that statement:
- More dependencies doesn't necessarily mean more code. Each dependency could be small (and well tested).
- "More code" doesn't necessarily imply a higher percentage of bugs per amount of code.
- Having more dependencies doesn't necessarily mean I'm calling more functions or hitting more code paths.
However, a larger codebase will tend to have more "pieces" of code that can interact, which will tend toward combinatorial growth in the number of ways to (mis)use those bits of code. If I have more dependencies, there are more pieces of code interacting and exponentially higher potential for bugs. So, while I listed out those qualifications, I don't believe they are the norm.
On the other hand, if I need some functionality, then either I use a dependency the provides the functionality, or I implement whatever it is myself. In that case, I'm taking a bet that my code will be better tested and more correct than the library author's code. In most cases, I think I would lose that bet.
Agree. As long as your dependencies are good so you don't need to open the hood then don't worry about it.
I just accept it: I'm not an artist or an F1 driver, elegance and unparalleled performance in the code shouldn't be my concern as long as it is solid and works. I'm in the business of solving business problems, not at scale, not in realtime but on a shoestring budget.
