Dependancies are Bad

This entry’s going to be relatively short. I wanted to point out something that I find very odd.

In the software industry, we strive to eliminate code-duplication. Duplicated code is duplicated effort, duplicated errors, and duplicated complexity. Yet I hear the same thing cropping up over and over again in many different projects – “I’m not going to use xyz, because it adds an extra dependancy”.

Are dependancies so bad that we can’t stand to see just one extra one in the aid of reducing code duplication?

My feeling is that the reason that people don’t want to do this is that the dependancies are often pretty heavy weight things. What they’re really complaining about is that “xyz” covers too much, and that they only want to use a small part of it.

In the interests of increasing code reuse then, I’d like to suggest to everyone one simple task. Release packages, release many packages, release small packages. Small packages are great, because people won’t see them as great monolithic blocks that they don’t want to depend on. Bottom line: if a package can be split into two in a reasonable way, do it! Oh, and one more thing: for the love of god, do it in an open way!


8 comments on “Dependancies are Bad

  1. 7kittens says:

    It is the same problem everywhere; a simple javascript library is very stable but do you really need that overhead for your users. It then becomes a scenario does bad by default even if it has no bugs etc.

    Also, good code is usually not written in one go; so just because there is something that can be reused it does not mean its the best design choice. Spreading crap frameworks with unreasonable overhead is not good practice.

    • beelsebob says:

      a simple javascript library is very stable but do you really need that overhead for your users.
      What overhead?

      Spreading crap frameworks with unreasonable overhead is not good practice.
      No, I agree, but this is another reason why I’m suggesting that people spread micro-packages. If one of the micro-packages happens not to be very good, then no one will use it. This allows evolution of a set of packages that are strong, stable, and small, and let us save writing that code all over again. 🙂

  2. Ex Girlfiend says:

    After reading the article, I just feel that I need more information on the topic. Could you share some more resources please?

  3. Hello, I can’t understand how to add your blog in my rss reader

  4. John m. says:

    I’m a bit late to the party, but as things have not improved much in a few years, here goes: It’s not necessarily a dependency, it’s dependencies of dependencies of that one dependency.

    Case in point: all the graphics packages. Instead of getting some tools to manipulate abstract geometry you end up depending on gtk2hs, gtk, cairo, the whole f**king gnome distribution etc. which adds up to a few GIGABYTES worth of crap totally unrelated to the problem you were trying to solve. And surely it will not compile on OS X without days of tweaking. And if it did, it would look like totally out of place and it would be inoperable with whatever native libraries you might have. Or other Haskell libraries you’re already using.

    Not to mention the issues of combining several incompatible licenses and company policies.

    Separation of concerns comes to mind. Fist step could be for Cabal to list external dependencies in some way, as depending on another Haskell package might only be 5% of the story.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s