Marcio's Synergies 6

By Mario Garrido Espinosa

Overview: 

Using large doses of humor, tenderness and realism, "Las sinergias de Marcio" manages to shape a demystifying portrait, at the same time demolishing, of the life of computer engineers in Spain. Taking as the protagonist a professional by the name of Marcio (which is an infrequent name and, thus, any resemblance to reality will be a coincidence), the author discovers a hidden and closed world that we all believed to be very different: project management, the treatment of subordinates, the reward of efforts, the relationship between engineers, coexistence in the office, work trips, endless availability... All aspects of this type of occupation will be shelled out, without forgetting the surprising personal life of the protagonist. Immerse yourself in Marcio's seven stories, discover this close and endearing character and live his adventures narrated with the style, irony and cruelty of the stories.

• Language: English
• Publisher: BadPress
• Release date: Dec 1, 2019
• ISBN: 9781071516478

Book preview

Dedication:

To my parents and brother.

To all computer scientists.

To those who read this book by chapters in its first self-published version.

This is not revenge, it's just a fairy tale like Little Red Riding Hood's;

or maybe something that is told here is credible...

Author's note: In computer metalanguages it is common to indicate between the symbols ‘<’ and ‘>’ expressions that are either not reserved words or they are more complex variables or sentences. Taking advantage of this semantics, this book uses these metalinguistic forms to denote descriptions or characteristics of something or someone that are more important for the purpose of each story than its own name. For example, in the text we may find meanings of the type instead of, let's say, this other more colloquial expression: 'Paco'. In this way, the informed reader (that is, you right now) will know at a glance that we are referring to a manager; someone who supposedly has a certain responsibility, a boss or team leader whose profile has to direct projects and people; and who has to do it well since he has reached that position from what it is supposed by experience and knowledge. Therefore, we don't care if his name is Paco, Torcuato or Priscilla.

––––––––

This book is a work of fiction. The names, characters,

companies, places, texts, mails, events and narrated

occurrences are a product of the author's imagination

and any resemblance to reality is pure coincidence.

––––––––

#006 The Chronicle of a death foretold

‘He was so perplexed with the enigma he had been fortunate enough to have incurred many times in lyrical distractions contrary to the rigor of his science. Above all, it never seemed legitimate to him that life should make use of so many coincidences forbidden to literature, so that the death so announced could be inevitably carried out.’

Chronicle of a death foretold.

Gabriel García Márquez.

1

Subject: Farewell 

From:

To:

Hello,

In this ‘Chronicle of a death foretold’ which this project has turned into, in which we have seen many comrades march on the way to the company of the competition or leave, from one day to the next and with almost no time to say goodbye, urgently requested by other projects of ADRIN, it has come to me, in this case to be part of the second group. A few hours ago, I was informed and I'll have to be present tomorrow in the offices of .

So before starting this new journey, I wanted to say goodbye and thank you for all you have been able to teach me and who knows, 'ADRIN is a handkerchief' and maybe we will meet again .

Best wishes to all of you.

And finally, here I leave what Julio Iglesias said in one of his songs which applies perfectly to this case:

‘In the end, the deeds stay

And People go,

Others who come continue on,

Life stays... the same...’

The farewell mails of a project or because of a change of company are a literary genre where it is usual to use this so computerized practice of code reuse. The improvised scribes confronted for the first time with this lyric usually follow different techniques: some of them are more extensive than the others; The text can be written with good and heartfelt prose or it can be a syntactic disaster where it is difficult to find a well-constructed phrase (perhaps it is a defect due to always writing in programmatic languages and thus involuntarily neglecting human ones); the one who is leaving may perhaps tell the reasons why for the farewell with just resentment or perhaps be cautious, suspicious about the future consequences that in the ‘computer world’ may have some written truths which are too much explicit and uncomfortable. As we can see, there's a bit of everything but in general the same things are always said. In the example given at the beginning of this story we see the final mail of a consultant who endured for almost five years the miseries of a project where things had been done badly from the beginning and where it was gradually creating an unbearable situation that was impossible to be reversed. As we have learnt at this point, it is common practice not to negotiate well with the customer and assume absurd deadlines. In our history we are going to deal with a clumsy and lying supplier and a fierce customer who knows it and takes ruthless advantage of it. Any of these behaviors could achieve the impossible because, as we know, what is not possible is obviously 'impossible' and no matter how much you push, scream or demand it, such developments will not have the minimum quality if they are not done with the necessary deadlines and tests. Then the new functionalities that are put into Production do not work and the customer gets angry, when he is the main responsible which he will never recognize. As a result, the supplier makes new concessions as he is becoming more and more enslaved to his own clumsiness. And the customer knows it and pushes even harder. Thus, there's a badly tested code pass again, or not tested at all, and it doesn't meet all the functionality. And accesses to databases embedded in the code or subroutines that have to be executed a thousand times, for example, they are botched and unoptimized, the result of speed, tiredness and restlessness, which in the short term slows down the application and in the medium term causes the system to burst. Then the servers that ‘serve’ (hence their servile name) the applications that we see when we enter the Internet fall down or restart. And while all this happens and everything is restored, the application does not work which for the customer is  a synonymous for apocalypse and the end of the world even though his activity is the sale of espadrilles, which nobody doubts is very worthy and commendable (we say the activity in essence), we can infer that it is nothing strategic. Once again the customer gets angry and upset, redundancy intended, crisis meetings where he asks for explanations that nobody has because there has not been a second to investigate the causes of the disaster, since the priority is always to make the application accessible again and, once restarted, there are not always evidences with sufficient quality to be able to investigate. After all, the system works normally again and the problem is solved, which is essential in order to be able to monitor erroneous behavior. But the customer neither understands nor wants these details. In spite of this, the customer asks for an explanation of the problem and its solution in an immediate term (sometimes written in a martial document format), with which the supplier sometimes has no choice but to use imagination and inventiveness which are tools that in the literature genre of fairy tales become in a great ally. However, such resources are the worst enemy of a computer project because in this sector, time unmasks any falsehood. Relentlessly and at the worst moment. It never fails. At this point the customer already has in his hands a cowardly and lying supplier who will not hesitate to handle at his whim. He swallows with what is commanded even pulls down his pants and begins to consider that the work week has seven days and nights; or eight or nine if physically possible. The customer is not satisfied with this and asks for high quality software without investing a second in the infrastructure maintenance which also end up being a problem. The supplier does not spend a single minute negotiating the crazy deadlines imposed by the customer and goes back to load up the code hastily without testing and praying that this time it will not cause too many problems. Therefore, there is no God who wants to get into such modern and far from the faith mess. Then the customer demands new conditions, such as crisis committee twice a day or conference calls every two hours or require the physical presence of one or two professionals from each field 24 hours a day...The imaginary of a malicious and angry customer would leave the Devil himself speechless. And the supplier says yes to everything again...The terrified reader would think these bad practices continue on both sides until death or eternity and so on. Well, I don't think so. Because death would be a sweet and seductive solution. We already know that the computer scientists' life is nourished by tragic and horrendous decisions. So, in this spine-chilling story, we will delve into the usual conclusion of these cases: They take the project from the supplier and give it to the competition. Of course, in three or four years this dynamic will occur again with the new company, perhaps with greater virulence, because human beings never learn from the mistakes they do not recognize as their own, especially if they are right under their noses. Thus, during the remaining months of life with this customer, the original consultant will have to suffer the worst of nightmares without having recovered from the hell of recent years. This final situation which no human being would have to live is called ‘the transfer’. Of course, I'm talking about Spain.

For our story we are going to imagine a project that is about to reach this situation of transfer but it does not still know. The code of the application that manages and evolves is at the limit being patched on all sides, springing a leak in more places than can be filled. The project management always gives priority to developments over the maintenance, the update of the hardware and products where those developments run on; and the customer does not give any importance to this second section either because of the obsession with selling his goods through his website. The supplier earns much more money with the developments (ten, twenty, thirty times more) which does not exclude the fact that he neglects the systems because it is known that projects always fail from the basis or the quality of the production