During its early days Multiplitaxion Inc, was a dramatic company with equally dramatic projects, every single one of which could have been quite literally turned into a small documentary or a movie. Of those projects a particular one, which for the purposes of this post, we shall refer to as 'Project-Rocket-Science' introduced me to, what I later started referring to as F@#K-YOU-Code.
The story started out with Fred intimidating a team member to write a piece of code that would transmit a file over a message queue which would then, at a later stage, transmit the file over to the client. The message queue was locked down there were serious issues with submitting requests to it.
Both pressure and intimidation on the developer were increased to get the job done on time so much so that we could see the tension in the developer's eye. He was quite literally working sixteen hours a day and was getting seriously nervous about the fact that he was facing a problem and no-one cared to help. Every time he went to Fred seeking help he returned, with his hands full of insulting remarks.
Then one fine morning it happened. The Breakthrough. Clicking the 'transmit' button on the screen showed the message 'file transmitted' and the entire team rejoiced. Soon multiple other complicated problems in the project started getting solved almost magically. The project was back on time, and the pressure and intimidation-levels came down.
A couple weeks later, as the project started nearing the testing phase, two of the best developers, including the developer who was working on the file transmission piece resigned and left the organization. Then others started following.
The couple of guys that remained in the team continued with the project.
A few days later, as the project moved into the testing phase, a tiny little bug appeared on the bug tracking system which was titled --- 'File is not getting transmitted when the transmit button is clicked'.
When Jack, who was a young and budding developer was brought over to the project and assigned this bug; he decided to study the code and get to the root cause of the bug. It took him less than ten minutes to get to the root cause and when he showed us what he had found, every single one of us laughed inwardly and at the same time we felt a chill run down our spines.
Embedded behind the click event of the button were two lines of code which read:
// No immediate fix was found for the file transmission issue. Will be fixed later.
Response.Write("File Transmitted.");
Jack, said in a as-a-matter-of-fact, cold blooded tone - 'it is not a bug. The code never did anything other than display a message of successful transmission'
Then after a long pause, he remarked, 'why would anyone do something like this?'
My response was rather spontaneous and unplanned --- It's F@#K-YOU-Code. That is what he wanted to say when he was writing this.
The person who wrote the two lines wanted to send a very clear message to Fred through these two lines of code, before he got sick and tired of the insults, the intimidation and the pressure. Before he resigned, he had cracked the biggest practical joke that I ever saw in my career and it took us two weeks and a QA cycle to catch his practical joke. By the time we did, he was gone.
But the dramatic twists of this real life story do not end here.
When Jack went back to Fred, and tried to explain to Fred how what he was trying to fix was not just-a-bug. It was functionality that he would implement and that it would take time, Fred pretended like he was not hearing English but a totally different language.
Jack was now under the intimidation and intense pressure spotlight. Jack worked for two weekends and spent more than sixteen hours a day trying to replace the two lines of practical joke with genuine code that actually transmitted the file. Then on a Friday Jack was told that he was causing the project to stall and the fact that he was not being able to resolve a simple bug, was causing serious doubts on his competence.
The following Monday, we heard about Jack's resignation. This bit was expected.
What was not expected however, was that, on his last day, Jack logged into the bug tracking system and marked the bug as 'Resolved' and in the comment field added a line - 'resolved using the same approach of original implementation'.
As you would expect, the bug of course, was not resolved.
When we asked Jack what he meant by what he wrote in the comment field of the bug tracker he responded with a rather sarcastic smile. We knew what it meant - 'F@#K-YOU-Code, F@#K-YOU-Resolution' - the bug was quite literally 'resolved' using the exact same approach of the original implementation. Jack did not do a thing to fix the code. He just went to the bug tracker and marked it as resolved on his last day at work.
Three weeks after Jack resigned, the organization discovered that all the other complicated problems in the project that had started getting fixed were also fixed using F@#K-YOU-Code, written by people who had planned their resignation and left before they were caught.
The project went into a nose dive.
As someone who was not directly connected to the project, I saw the team members who were directly connected run for cover. As for Fred, no-one did a root cause analysis of why the project failed and Fred was moved to manage another project.
Of-course, no-one in the 'upper management' could have even thought about developers writing F@#K-YOU-Code as a symptom and intimidation as a root cause for a project failure.
They were busy looking for more complicated reasons like - The-Requirements-Were-Not-Clearly-Defined or The-Scope-Was-Not-Correctly-Measured.
Even though this was a hugely dramatic, one in a million example of F@#K-YOU-Code that you get to see in your professional life, even today, every once in a while I see developers write subtle examples of F@#K-YOU-Code every time they are cornered using tools like insult and intimidation. Of-course they don't plan their resignations and crack practical jokes as huge as the one I witnessed, but every time they are cornered, chances are that they will litter the codebase.
They will leave a broken window with a F@#K-YOU-FOR-CORNERING-ME message silently and subtly embedded in the codebase without even knowing or fully realizing that they are doing so.
F@#K-YOU-Code might be causing your project to fail right now and you may not even know it.
Talk to your developers, make them feel at home, do not (and I cannot emphasize this enough) use an intimidating or a condescending tone while talking to them. Encourage them to bring problems out in the open and when they do, stop playing the blame game and help them fix the issues.
I wish you good luck.
Comments are closed.