A surprising chain of events took place in March 2016 when a man from Oakland, California deleted a fragment of code and caught thousands of web developers off-guard.
Although news travels at lightning speeds and goes stale quickly nowadays, this topic is still worth writing about because it carries information that will be significant to programmers for years to come.
The Story
Azer Koçulu disrupted thousands of projects when he decided to delete the left-pad package, which consisted of only 11 lines of his code. He previously published it to npm, which is a popular platform for finding and installing open source software written in JavaScript.
Azer created a package for programmers that helps them easily set up templates. The problem arose because he named his open source package “kik,” which is the name of a popular messenger app whose developers also use npm.
Kik’s representatives were worried that the users would be confused by the name of Azer’s package with being one of their own. That is why the company decided to contact the programmer to ask him to rename his package.
Since npm is an open source community, Azer did not think that they had the right nor the power to make him change the name of his package. But he was wrong. Npm sided with Kik and forced Azer to leave the community.
Npm decided that siding with Kik was in the interest of its community members, because the company boasts a large user base. Therefore, they thought it was wiser that Azer change the name of his package. But the programmer did not like this at all.
Kik hired a patent lawyer to contact Azer for the purpose of changing the name of his package. After an exchange of emails, contractor Bob Stratton realized that Azer would not back down. The Turkish developer had strong belief in the open source philosophy and did not want to cooperate. The company then contacted npm directly.
Azer’s last message shows his dissapointment.
“Isaac; I’m very disappointed with your decision here. I know you for years and would never imagine you siding with corporate patent lawyers threatening open source contributors.“
Koçulu did not want to change the name of his package, so he decided to remove all of his contributions from npm. He stated that he does not want to be a member of npm anymore and asked them to remove his packages or to instruct him how to do it himself.
Then There Was Chaos
Just two days after the last email from Koçulu, npm realized that they have a problem. But unfortunately, they were not the only ones. Thousands of programmers from around the world started to receive a mysterious error when they tried to run their code.
The error made it impossible for developers to update certain apps and services. There was one line of code that stood out more than anything else.
From this error message, it is obvious that the code could not run without a package called “left-pad” and npm did not have it in their registry. Most programmers did not know about this package until it appeared on their monitors.
All software is built on top of other software which is also dependent on other pieces of software and so on. Loading an app might require packages from npm that are dependent on other packages as well.
Npm’s popularity lies in the fact that they help manage these dependencies by maintaining them in a reliable place. But that reliability quickly turned into chaos when one crucial piece of code was removed.
This is a situation which could have possibly been resolved with better communication, a group chat, staff scheduling, or some other apps or software for project management. Unfortunately, the damage was too great to be fixed with technology.
The Notorious Left-pad
Since it is not often the case that a package goes missing, developers began discussing this problem at the GitHub repository, where left-pad was maintained. As you can see, this package contains only 11 lines of code, which makes the situation even more ridiculous.
Though most programmers relied on it, left-pad is a single-purpose function which any programmer can write on their own. The code is merely used to add characters to the beginning of a string of text: a zero to the beginning of a string code, for example.
The absence of the code affected developers on an international level. Programmers from Australia, the Czech Republic, Germany, and Ontario were all commenting on the left-pad’s GitHub page. The left-pad absence was detrimental to many corporate giants, one of which was ironically Kik.
Kik’s developers noticed that they couldn’t work on their software because they were missing a certain package they knew nothing about. One of the packages created by Facebook called React was also affected. The package is used by the tech giants Facebook, DropBox, and many other services.
As its programmers could have easily written code similar to left-pad in its original construction, React certainly did not need those 11 lines of code. Rather, its coding depended on a set of packages that depended on another set and so on. Somewhere down the line, React developers had relied on left-pad, which was now missing because Azer took it down.
The Detrimental Dependencies
It is interesting that all modern software often depends on a tiny piece of code such as left-pad. Even Facebook depends on lines of code written by open source developers. This got the online community riled up.
It became evident that npm’s infrastructure was not as safe and secure as once thought. Programmers also criticized npm for giving in to Kik’s demand. They thought it was unfair to take away someone’s module like that.
Some developers made fun of the fact that this would not happen if programmers wrote the 11 lines of code themselves. They even created a funny website called leftpad.io to prevent such future failures. But now, the open source community is at risk. It seems as though the big companies have an influence on the community.
Unprecedented Republishing
It is clear from this that the open source community is not that concerned with the needs of the people; rather it could be easily influenced by the corporate giants.
Azer Koçulu realized this and took down all of his 273 modules in protest. He explained the misunderstanding between the three parties in a blog post entitled “I’ve Just Liberated My Modules,” one of which was the notorious left-pad.
After causing so much havoc, npm decided to republish this package. This is an unprecedented decision, as tweeted by their CTO Laurie Voss. He explained that npm had to choose between the needs of one user over many, so they sided with the latter for convenience’s sake.
Have We Forgotten How to Program?
Some programmers tend to think that the entire software ecosystem is built as a house of cards and that the whole construction is rather weak. This idea is backed by the left-pad incident, since all it took for the internet to “collapse” was a minor dispute between a developer and one messaging app.
It is quite ironic that the system crashed because of one community member’s package and then was put back together by that same community through quick and responsive organization. The open source community is like a high-performing organism.
But there is one question that arises from all of this, posed by Stack Overflow’s engineering manager, David Haney: “Have we forgotten how to program?”
He states that stringing APIs together does not constitute programming. He believes that it is a form of dependency hacking in the cloud and that it over-engineers the production of programs, making the process much more complicated than is necessary.
According to Haney, the worst thing about this is that you will not be able to fix a bug in the code if you do not know how to program in the first place. And every reasonable programmer knows that you cannot avoid fixing the bugs.
It Is a JavaScript World
This situation is actually created by JavaScript itself. It is a difficult programming language that might take years to perfect. Other programming languages include functions that make a programmer’s life easier, but not JavaScript.
Some programmers might want to blame developers for this state of affairs, but developers are not to blame here since they are only trying their best to make ends meet. The complexity of JavaScript and consequent developer needs are the reason behind the creation of the npm registry.
But there is a problem here. Some of Azer’s unpublished modules only contained one line of code. This is not something that one cannot program him/herself, and it is not something that you want to be dependent on.
If companies such as Facebook and Kik use these open source modules, it is not just these small pieces of code that will be problematic in the future. Rather, they have to think hard about all the single-function modules they are using, which are created by third-party developers. They might find out that their build actually is similar to a house of cards.
The NPM Micro-package Fetish
The problem is that many programmers, especially in the npm community, have clearly given up on coding and substituted it with a bunch of connected dependencies. It is almost as though they have developed a fetish for micro-packages. It looks like that the npm community programmers just write tiny pieces of code they use to string together all the available library calls.
This is by no means a long-term solution. Programmers should always rely on themselves when it comes to writing simple code. If we only use dependencies someone else had created, we will lose our coding skills, which will ultimately result in failure.
Functions Do Not Equal Packages
Pure functions are random parts of code and nothing else. They are not big enough to make it into a dependency or a package. Nobody needs a cosine dependency. Instead, what programmers really need are trigonometry dependencies.
The point is that we need dependencies for something that is difficult to create and has many tricky functions. Most of us want to avoid creating them on a case to case basis. .NET and many other frameworks have a library of basic functionality with all the essentials included. These kinds of libraries are created by professionals and are guaranteed to be bug-free, so they might prove useful for programmers.
Third Party Problems and Dependency Hacking
Writing the code yourself is a major part of guaranteeing its efficiency. Only you can modify the code to be the most optimal solution there is. This is not to say that the code written by somebody else is worthless, but it might be a bad choice for your particular needs and this is where it gets interesting.
Do you actually know how to code?
It is amazing that this whole situation happened because many programmers were lazy enough not to write only 11 pieces of code. If you have trouble writing a function that does what left-pad does, you might want to consider learning how to code.
You just cannot string APIs together and call it programming. The best name you can give to something like this is “dependency hacking,” and it is completely unnecessary because it has to do with over-engineering things and creating superfluous complexities.
Radically Limit Dependencies
With every package comes another dependency. Without them, your code will not be able to function. If you have a small number of dependencies, you will have less points of failure within your code. If you do use a small number of dependencies, think about whether you have vetted the programmers who had written the code.
Use dependencies only for the most complex functionalities that would take too much time and resources to code yourself. For example, a database layer or a caching client could use dependencies because they are worth the efficiency and the savings.
A function like left-pad you can write yourself. Do not learn this lesson the hard way.
Azer Koçulu really made the programming community think about several things. For example, why can a company influence the actions of an open source community? What is the problem with JavaScript dependencies? Do I know how to code?
We have to understand that shortcuts can sometimes lead us astray and that writing 11 pieces of code can save you or your company a ton of money. Although this affected multiple companies and thousands of developers, the lessons learned are essential for any budding programmer.
