1. 41

Most interesting quote: “I guess that explained why Excel had its own C compiler.”

  1.  

  2. 17

    My current mantra at work is “eliminate dependencies”. I think alot of developers think something like: “Oh, I need to do X. There is a library for X. It’s free. Surely I will be better off using that library and those library authors are experts at X and I can focus on delivering business value”. For some values of X that’s a pretty reasonable assumption. I use lots of libraries every day. I use an open source kafka client that I could and probably never would want to write myself.

    In fact, the core competency of my team is serving web requests and we rely hugely on go and net/http lib to provide us with keepalive, transparent h2 support, a scalable epoll based network handling stack, etc.

    But a dependency is never free. There’s no such thing. A dependency is something you have to understand and debug. A library likely tries to accommodate a very generic set of use cases for maximum reusability, and it’s quite possible you need a very small subset of that functionality. So it’s very possible that writing that one or two functions may very well be a much better choice than the ongoing work of importing a 3rd party framework, staying up to date while simultaneously managing risk of framework disappearing while also auditing the framework to ensure that it’s safe to run on your production servers. That framework may very well do it’s job in a very non-optimal way because it has to work in so many different environments and use cases (running on windows, or supporting Oracle, etc).

    As an extreme example, it’s unlikely that the left-pad library was worth the risk.

    Finally, and this is specific to my experience, alot of 3rd party services are just bad. I really hate having to tell someone that their site is down, but there’s nothing I can do, I don’t like to pass the buck or throw up my hands and say: “Sorry, your site is down until $provider X fixes their stuff”.

    1. 13

      Surely I will be better off using that library and those library authors are experts at X

      Maybe it’s because I do JS, but lately I’ve been questioning this more and more. Cynical, but a lot of library authors aren’t experts at X. I’ve switched to trusting a small list of reputable Node/JS developers (which is vague and in my head) and evaluating the need for a dependency for the rest. Maybe not fair, but it saves me trouble.

      1. 4

        I reached the same conclusion after evaluating my company’s dependency tree and finding problems with most of the third party libraries our code depended on. Some of them are described here:

        https://kev.inburke.com/kevin/dont-use-sails-or-waterline/

        I focus more on areas… I don’t want to rewrite a bcrypt hasher, or a postgres driver. But I’m definitely going to rewrite an API client for your API. In some cases I’ll steal only the parts of a third party library that I need, put them in my source tree and remove the rest.

        I also found most uses of lodash to be totally unnecessary and increasing the complexity of the code inside.

        1. 1

          I wonder if you’d be willing to share that list? I’m outside of the JS modules community. However merely publishing the list could cause drama, which I wouldn’t want.

          1. 5

            Like I said, it’s really vague and all in my head. It’s probably not even a list, just people I recognize from my 3-4 years doing Node. Sindre Sorhus, TJ, Dominic Tarr, Max Ogden, Mafintosh, among many others come to mind right now.

            I also give more “points” when the project is in a company’s GitHub, because then I can a) have some confidence more than one person looked at the code and b) learn about the company—they could be a top Node agency or respected in their field.

            If you want to summarize my method, it’s really just “don’t install too many dependencies with little activity and made by random people”. Another point is that most people (including me) don’t live on GitHub like prolific authors sometimes do and ignore or forget about project issues and pull requests.

        2. 1

          Dependencies are definitely a risk as sources of bugs but I do not believe we should eliminate them. Instead of eliminating dependencies, alternatively you can structure your code in a way that switching out libraries/dependencies is easy. Dependency Injection would allow you to modify or replace the object that’s creating the issue.

        3. 11
          1. 3

            After terrible experiences in Rails land, I’m tending towards this attitude. Much of dependency hell stems from trivial libraries that I could implement in an afternoon, often without a bizarre decision or two that serve to make the most popular library “unique.” The worst is when the most popular solution for problem A monkeypatches the same thing that the most popular solution for problem B monkeypatches.

            1. 3

              Relatedly, I’m a strong proponent of reading a potential dependency’s source before taking it on. When something goes wrong, you’ll have to, anyway, so you might as well do it eagerly and avoid any nasty surprises (“our product was built on this garbage all this time?”).

              I feel like there was a decade or so when everyone pushed so hard against the perceived evil of NIH that we went too far in the other direction. The success of FOSS has both helped and hindered this — you can’t read the source of a dependency if you don’t have that source, but on the other hand, so many dependencies being free-as-in-beer has allowed people to believe that there is no cost to using them.

              I think Benefits of dependencies in software projects as a function of effort was probably discussed here recently but it’s worth mentioning here since I think it makes a more nuanced point than Joel’s article.

              1. 1

                If you don’t have the source of a dependency, the containing project is not open source.

              2. 1

                Argh, can’t hide photo, too distracting, can’t read article.

                1. 2

                  /usr/bin/lynx :)