3 ms·
Compare and contrast with “the curse of JavaScript” which is the opposite problem of an explosion of dependencies and the management thereof. The business guys
by recursivedoubts 2y ago
Compare and contrast with “the curse of JavaScript” which is the opposite problem of an explosion of dependencies and the management thereof. The business guys might not like it (“it’s too hard to replace engineers”) but, from a software engineering perspective, a tendency towards fewer dependencies is better for the system.
- ironmagma 2y agoThis gets at an interesting nuance. The under-reliance on dependencies actually poses issues at a system level, not at an individual product level, which makes it hard to sell business types on the existence of the problem. Is it really hard to replace engineers when you have a lot of dependencies? A lot of dependencies means a lot of things you have to learn. Let's consider the case where every line of code invokes a different dependency. That's clearly insane and not the ideal case, even if they are all well-known dependencies. Everyone on the team will be constantly chasing down documentation for the dependencies they don't know. The optimal point is somewhere in the middle. I just am pushing for more dependencies because I see it being too far in the "no dependencies" direction.