
Friday's deployment
In the project documentation, someone, an unknown user, added a story about the production deployment that took place last Friday, the day of the earthquake.
The story explains the causes of the incident during that fateful deployment. Its protagonist is a developer, an unknown developer, working in a makeshift office set up in his living room.
The developer works remotely and holds meetings with colleagues in other parts of Europe. He is proactive and responsible, and he enjoys his work, so he works diligently. And he drinks coffee.
“You have to stay active” his grandfather would tell him when they went hunting wild boar on the family estate over the weekends. He’d take out his steaming thermos of coffee and offer it to his grandson, who years later would specialize in software development and leave wild boar hunting behind.
The developer doesn’t have time to go down to a coffee shop. Instead, he goes to the kitchen and prepares coffee with his Italian stovetop coffee maker. He types a bit of code until he hears the coffee brewing.
The most important thing is to have a saucer for the coffee cup. With one hand, you hold the saucer, and with the other, the cup. That’s how coffee is drunk. You lift the cup lovingly and bring it to your lips. The lips should touch the coffee, which may cause a drop to escape and fall, potentially staining the floor tile. That’s where the saucer comes in; the drops rest there.
And so, calmly, in a state that could last all day, you can gaze out the window while sipping coffee and observing things. But one must stay active.
The developer’s next task was due shortly. The meeting topic was the production deployment of the new web app. He needed to update the configuration, nothing out of the ordinary for deployments.
The developer had everything ready: the portal was open, the chat session was active, and his inbox was clear, awaiting any message or issue that might arise. His chair was properly centered, with his back comfortably reclined, and the coffee next to the keyboard, within reach.
It was a sunny Friday. And then the time for deployment arrived—12:00 p.m. Just when the sun was at its peak.
The developer entered the command in the terminal. Everything was fine, according to the machine. Everything was fine, according to the chat statuses. Everything was fine, according to the emails.
The developer extended his arm as if reaching for a flower, picked up his coffee cup, and brought it to smiling lips. “All good,” he said to himself.
Then it happened. According to the documentation, Friday's earthquake was mild. Without specifying the magnitude, it notes this as the cause of the failed deployment.
When the ground moved beneath him, the developer was startled. There had never been an earthquake in his neighborhood. The lamps swung, some glasses fell, and the developer spilled his coffee outside the saucer. Clumsily, the developer tabbed on his keyboard and accessed the delete command. This is how the entire project repository and content were erased.
This last detail isn’t in the project documentation, but I managed to include it here thanks to a pull request review where the developer admitted to his mishap.
In any case, the deployment was a failure. The client couldn’t test their application, and the company lost that contract. Many users complained, left negative comments on social media, and advised other clients to end their negotiations with the company.
Then, the company went on its knees and explained they had chosen to deploy that Friday for the users' convenience, so the app would be ready for testing first thing Monday morning. The company truly cared about the users. Were they to blame for causing an earthquake?
The clients and users accepted this and gave the company a second chance. They’d reflect over the weekend; some would go boar hunting, others would go to the movies with their families. And they’d return on Monday morning to test the application, with loaded shotguns.