A long time ago, in a world far from real life, there were six programmers who spent hours competing among themselves to see who the best software developer of all was.
To prove their knowledge, the programmers explained the most fantastic stories about algorithms they could think of and then decided among them who the best programmer was.
So, every afternoon they gathered around a table, and –very slowly—read the most voted debates of that week in StackOverflow while Jenkins’ last task compiled. The first of the programmers adopted a stern attitude and began to tell the story that, according to him, he had lived that day. Meanwhile, the others listened somewhere between incredulous and fascinated, trying to imagine the scenes that he described in great detail.
The story was about the way in which, finding himself free of occupations that morning, the programmer had decided to download the V8 source code, and cross-compile it for all the devices he had. The programmer said that suddenly, in the middle of a great surprise, Linus Torvals appeared to him, took a PC with Linux out of his backpack, and compiled with great mastery the Linux kernel at his side. Upon receiving praises from the programmer, Linus decided to grant him the power of the Clean Code, which according to him, made him one of the most talented programmers that existed.
When the first of the programmers finished his story, the second of the programmers stood up, and while moving his hands on a Leap Motion, he announced that he would talk about the day he had witnessed the famous presentation of the Swift language, the innovator and interactive Apple language. According to him, this happened when Tim Cook himself called him from the Cupertino offices to invite him to the most anticipated Apple event of the year, he said all this laughing while caressing his coffee cup with the JAVA logo printed on it.
To be up to the previous stories, the third programmer turned on his computer and showed its interface full of Node.js terminals and servers running in real time. After having tried Node.js in production, the programmer spent countless hours talking about the great response time that Node.js had against other platforms such as Apache’s httpd.
Next, it was the turn of the fourth programmer, then the fifth, and finally the sixth programmer was immersed in his story. In this way the six programmers spent the most entertaining hours while showing their ingenuity and intelligence to others.
However, the day came when the calm atmosphere was disturbed and turned into a confrontation between the programmers. They could not reach an agreement on the exact way to make a release to production. The positions were opposite and since none of them had ever made a release to production, they decided to create a document in which each one would think about how the release to production process should be, thus clearing the doubts.
As soon as the Google Apps administrator created the document, the programmers began to outline their ideas about it. It had not been long when suddenly, they noticed a change in the twitter timeline of a list that everyone was following. A tweet appeared on how Amazon made its releases to production. They quickly clicked on the article, since they had the Canary version of Google Chrome compiled by themselves, the article loaded in milliseconds.
The six programmers were full of joy, and congratulated each other on their luck. Finally they could solve the dilemma and decide what was the real way to make a release to production.
The first one, the most determined, put his reading glasses on to start without further delay a slow and quiet reading of the article. However, the rush caused him to accidentally stick a leg of his glasses in his eye, preventing him from reading the entire article.
“Oh, my colleagues!” He exclaimed, “I’ll tell you that a release to production can be done perfectly with Amazon S3’s Java API.”
It was the turn of the second of the programmers, who read more carefully, he printed the article on some sheets and proceeded to read it with a dim light on his head, while he was lying in his favorite puff, with such bad luck, that he fell asleep reading the second page.
“Oh, my brothers!” He exclaimed when he woke up, “I’ll tell you that the best way to make a release, is to create a task in Jenkins that uploads the binaries to S3!”
The rest of the programmers could not avoid to mock him in a low voice, since none of them could believe what the other programmers were saying. The third programmer started reading the article on his Kindle. After a long afternoon reading, the device ran out of battery enough for the programmer to read the last 30 pages that were missing,
“Listen to, my dear colleagues, the Amazon release process can be done with S3cmd.”
The other programmers silently disagreed, since nothing resembled the release process that each one had in mind. It was the turn of the fourth programmer, who decided to telephone his friend who worked at Google. The programmer asked his friend what release to production process they were following at Google. He listened carefully to all the steps and wrote them down in his notebook to keep record of the effort he had invested in learning Google’s release process.
“I got it!” Said the programmer full of joy, “I’ll tell you the real way to make a release to production, you just have to relocate the servers and synchronize Jenkins tasks to deploy the latest commits of repos.”
The fifth of the programmers took over and decided not to read the article since it seemed irrelevant. He recalled that 15 years ago an IBM engineer published a book on good practices on deliverables in JAVA projects.
“None of you have found the way to make a release. The traditional method of making a release to production in serious companies, is to stop the services with a ‘maintenance’ message and deploy changes on all the necessary machines.”
The sixth programmer was the oldest of them all, founder of several consultancies in the country, he knew the ins and outs of production releases, or so he thought. He reviewed his personal email and found those documents on functional specifications that described every necessary step to make a release to production, even specifying the color of the buttons and the design of the error windows.
“Colleagues! Without a doubt now I have it clear. The correct process to make a release to production consists of bringing together the heads of the project and delegating the tasks to the programmers of each team.”
Now everyone had experienced the correct way to make a release, and they all believed the others were wrong. They satisfied their curiosity, returned to shake hands, wrote their point of view in the document, and sat back in their computer stations proud of the time they had invested in writing that document.
Once again sitting under the same office light, they resumed the discussion about the real way to make a release to production, certain that what each one of them had experienced was the right way to do it.
Probably all programmers were partially right, since somehow all the things they had experienced were true, but without a doubt, they were all wrong about the real way to make a release to production.