There was a popular post going viral on the internet recently. Just a simple post of a simple man adding a single line of code that made it so that there was always the project that would just not run right. Random chance, like some game of online poker. You may or may not have seen it depending on which communities you keep up with on the internet.
But to sum up what it was all about; the story goes that some disgruntled office worker had been working on some project or another for quite a few years. One of those workers that have been in the company longer than anyone. So it goes that (as is all too common in any industry) this worker was treated badly near the end of his career at the unspecified company. When he finally quit and moved onto hopefully bigger and better positions he left a single line of code in the middle of some large and non-suspicious-looking file in the database. The line went like this:
“# define true (rand() > 10)”
In the infamous post itself, it included a little comment above that line of code that just said “Happy debugging, suckers”. The sweet cherry on top you might say.
From a bystander’s standpoint, this is actually quite funny. I mean just think of the poor intern who can’t figure out why his basic if statement isn’t working only some of the time. When running the program, once it works and then running it again without changing anything and it doesn’t.
But when you think about it for a little longer you realize that it’s actually kind of scary. A single employee with the ability to unchecked input whatever code they want and cause single line of code whatever danger they want? Especially right before they are going to leave the company? Surely a company shouldn’t allow this much power to an employee. And surely there are some methods for making sure something like this doesn’t get through to the final production product?
Ways to stop this from happening to your company
There are quite a few quite simple methods you can use for stopping stuff like this from happening at your company before you get into more complicated methods for stopping stuff like this from happening at your company. The first one should always be don’t let people upload directly to the main branch. This might seem very basic but you’d be surprised how many people don’t follow this. This is also another reason on a long list of reasons why you should always use a program like GitHub on any project.
GitHub is a very popular software development hosting software. By very popular I mean pretty much universal. And for good reason too. Because on GitHub everything can be very easily managed. When someone uploads something to GitHub it doesn’t just override the original main code. It goes into a sort of separate thing that needs to be committed to the rest of the project. So this means that people could continue working and upload their code without writing over the main code without any oversight.
It also has a commit log which logs everything that anyone does to the project. So if a single variable is changed in a single obscure file somewhere it doesn’t just go under a useless tag like “changes made on Sept 4” or something even worse like “project modified on Sept 4”.
With technologywolf, you’ll see exactly which files have been changed in the version being uploaded, exactly what has been changed in the files and where exactly in the files the changed code is (It does it by line, like an error message in a compiler), who was the one who did the change and even when the change took place down to the minute!
I don’t think I really need to explain why each of these by themselves can easily help a company stop someone from causing havoc in a project. At least as easily. There are other methods that could be employed too to better help to stop things like what was mentioned in this article from happening. Simple ones like having a set time were peoples’ changes get committed to the main branch and at that time you have some people check what’s in the changes to make sure it works and it’s not detrimental to the project
