Becoming Too Dependent On Code

Code dependency is a topic that rarely gets talked about in programming circles. Mainly because it's something that everyone does and doesn't really put much thought into. This file requires that file, and this module requires this installed, and this file comes from a CDN that may or may not work tomorrow. And there's a risk and there's a benefit to this whole intermingling thing. For one, it becomes much easier to create software. Not much faster, which is important, but much easier. For example, back in the day, doing any type of animations on a website required timers, math and a creative eye. Nowadays, you link to jQuery and you're done. It's simpler, but you still have to be familiar with jQuery library and all of it's intricacies. So it's simpler overall, but may not save you much time in the end, particularly if you're a more experienced programmer.

Just recently something happened on quite possibly the largest scale we've seen so far, that brought the risks of code dependency to light. Many people heard about it, and many people pointed fingers and complained and such because it affected them. And it really just came down to one sole developer who decided to take his work and go elsewhere. A programmer by the name of Azer Koçulu decided to unpublish more than 250 of his modules from NPM, a very popular JavaScript package manager. What happened next was somewhat unexpected, but something that was bound to happen. One of those modules was an 11 line script titled left-pad that resembles the following:

module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
}

Unfortunately, projects like Node and Babel relied on this library. And thus, thousands of deployments from all over the interwebs failed in a Matrix like catastrophe. Which, was huge of course. Who do we blame and what do we do about it, were the big questions. And so the solution was to publish that sole library again, and just wait for everyone to forget once more and continue to build up this tower of code. This isn't the first time by any means that this has happened. There are countless projects littering the internet that have stopped support for years now. And it's at the developers risk to implement them onto their websites. And if you're one of the unlucky few to be using that library, then you might just be stuck continuing to rely on it.

We copy and paste code from the webs and we use libraries built by others in order to simplify our lives, and we even build tools to help make this even easier. They manage our dependencies for us. And one day maybe, those tools will also need to be managed by some other dependency object. It wasn't always like that though, and sometimes it's good to go back a bit and remember that a programmer's job should still be to program.

How Code Used To Work

Back in the day, like when I was in college almost 10 years ago, we weren't really allowed to just use 3rd party libraries to do our work for us. Most professors wanted every part of the code written by the student themselves. It was tedious, but really 10 years ago you didn't have the amount of 3rd party libraries that exist today. jQuery for example was released in 2006 and Bootstrap more recently in 2011. And since then thousands of others have hit the shelves for all to use. Nowadays you'd probably get a lower score for not using one of those libraries.

Which brings us to now. Nowadays, programmers need to be highly skilled..in knowing how to use other peoples code. Many won't admit it, but for the most part programmers don't work on their own code. They work on code written by many different people, many times using plugins and libraries written by many other people. Most of the time, they have no idea how said code works. But it has 8020 likes, so it must be solid. I do the same. It's just part of the job nowadays. Many times, managers have asked me to modify certain aspects of a widget or module, to which I have to respond that it is impossible, as it is not something built or managed by us. So for the most part, we just settle for what we have.

And My Own Experience

When Bootstrap first came out, it was the most amazing thing ever. People were finally able to get a decent looking website with the most minimal of effort. Then, every site in the world started using it. And it became "Oh look, a Bootstrap theme again". I myself have many sites that I built that relied on Bootstrap, and they pretty much can't render without it anymore. I've tried. After a recent audit on my website, led me to see that I was not using about 99% of the Bootstrap library, I attempted to remove it. And then quickly re-added it, once I saw the mess that made. The problem was that I styled my website on top of Bootstrap. So every margin, padding and position was based on whatever Bootstrap had done for me, and thus, I still have Bootstrap running. Well played dependency. Well played.