Many people think about the problems that concern them before falling asleep or upon waking up. I'm no exception. This morning, one thought popped into my head from Habr:
A colleague shared a story in the chat:
I had an amazing client the year before last, it was back when I was dealing with a pure "crisis."
The client has two teams in the dev group, each working on its own part of the product (conditionally, the back office and the storefront, i.e., the software responsible for order formation and the software for order fulfillment), occasionally integrating with each other.
The back-office team had gone completely downhill: six months of constant mistakes, the owners were threatening to fire everyone, they hired a consultant, and after the consultant, they hired another one (me). Meanwhile, the second team (storefront) was doing fine and continued to work well; it was the back office, which had also been performing well before, that started making mistakes. The teams are located in different offices and have grown accustomed to blaming each other.The reason: the store and back are part of the same system, with tons of dependencies, and the teams in different offices did not communicate with each other. The owners were constantly "watching" the storefront, leading to new features, ideas, and oversight. There was a jack-of-all-trades guy in that team, a combination of a BA, designer, and "bring us coffee" person. This guy, unnoticed by his team, handled a bunch of small tasks like "notify the second team about the deployment," "update documentation," and routine stuff, down to "entering version numbers and components in JIRA tickets." But the guy didn't write code, and at one point, the owners decided to optimize him out, firing him. For the storefront team, nothing changed; they simply stopped entering and updating documents, while the back office found itself in a situation where the storefront releases were breaking something on their end, and that became their problem. If their releases broke something for the storefront, that was also their problem because the storefront was under the owners' watch 🙂
What struck me about this comment, and what the seeker will find from the title — is below.
I have been developing web applications for about 20 years, so front-end/back-end are not just words for me. These are closely connected aspects. For example, I cannot imagine a situation where the front-end is developed completely (or significantly) detached from the back-end. Both sides operate with the same data, performing very similar operations. I have a general idea of the volume of information exchanged between the developers of both teams for coordinating development, and how often these discussions need to happen. The teams cannot avoid close communication, even when in different time zones. Especially with the presence of JIRA.
I know that notifying back-end developers about front-end deployments is pointless. A new version of the front-end cannot break anything on the back-end, while the opposite can happen. It's the front-end developers who are interested in informing the back-end developers that they need new or modified functionality. The front-end relies on back-end deployments, not the other way around.
What the boy who "bring us coffee" cannot be a BA (if by BA we mean "business analyst"), and a BA cannot be "boy, bring us coffee". And certainly, "to input various version numbers and components into JIRA" without discussion with the development teams neither the "boy" nor the BA can do. It's like a cart before the horse.
Since the "boy" was fired, those functions, from "bring coffee" to "input into JIRA", should have been redistributed among other team members. In an established group, information flows and roles are solidified; if the performer of one or more roles leaves the scene, the remaining members still require the usual information from familiar roles. They simply cannot miss the fact that the information necessary for their work has stopped coming to them. It's like a drug addict cannot overlook the cessation of their drug supply. Just as a drug addict seeks and finds alternative sources, group members will try to locate the needed information on that "side" and find new performers for old roles. And they will certainly find them. At the very least, someone they believe should provide them with the necessary information.
Even if we assume that the usual channels of information have collapsed, and the one who should act doesn't feel the need to, the backend developers under the threat of dismissal will not hide the reasons for their failures from the owner for six months, knowing that their mistakes stem from the lack of the information they require. Owners will not "fumble" for six months, seeing that necessary information used to be available,but now no one puts it in.And the first consultant was unlikely to be that unprofessional, not to talk to the backend developers and not to pinpoint the source of the problem — the lack of coordination between teams. This is precisely the reason for the described troubles, not the dismissal of the "boy".
The banal absence of communication between developers is a typical cause of a plethora of problems in development and beyond. You don’t need to be an outstanding consultant to identify it. Just being reasonable is enough.
I believe this entire story is fabricated and well-articulated. Not entirely made up — all elements are drawn from life (frontend, backend, development, boy, coffee,jelly,…). But they are connected in such a way that this construct doesn’t occur in reality. Separately, all these components can be found in the surrounding world, but not in this combination — no. I explained why above.
Nevertheless, it is presented in a very plausible manner. It reads with interest and there is personal involvement. Sympathy for the "jack-of-all-trades", the undervalued small mechanism of a large machine (this is about me!). A condescension towards developers, so smart and experienced, but unable to see beyond their own noses (they’re all around me!). A light mockery of the owners, wealthy uncles who created their own "ouch" and cannot understand the reasons (what a mirror of my management!). Disdain for the first "consultant", who failed to find such a simple source of problems (sure, one like that came by recently, wearing glasses, looking all smart), and enthusiastic unity with the "real" consultant, who alone managed to appreciate the true role of the jack-of-all-trades (that is me!), и восторженное единение с "настоящим" консультантом, который единственный смог оценить настоящую роль мальчика-на-все-руки (то есть меня!).
Do you feel a sense of inner satisfaction after reading this comment? Our role as small cogs in a big machine is actually not as small as it seems! It's wonderfully articulated, although it may not be true. But what a pleasant aftertaste.
I don't know who the colleague is or in which chat they shared this revelation with their peers. and why the colleague mkrentovskiy decided to publish it under the article "" of an outstanding Habr author ‘who, by the way, is currently ranked first on Habr!), but I acknowledge that the colleague mkrentovskiy did this remarkably well. The message of the comment and its style align so perfectly with the tone and style of other publications nmivan‘that one might think that the crisis consultant in the comment and the main character of many publications nmivan‘are the same person.
I have read quite a few publications by Ivan Belokamentsov since the author started on Habr (in 2017). Some even with pleasure (, ). He has a good writing style and an engaging presentation of material. His stories are very similar to real-life experiences, but they almost have zero chance of actually happening in . Just like with this story in the comment.
To be honest, I personally don't think that Ivan's publications have made Habr better. But his rating and of other Habr inhabitants say otherwise:
I don't understand your whining. Habr has long declined, but the author brings a bit of spark and lifts the readers' spirits ) helping the resource rise from the depths.
Yes, Habr is not charity; Habr is a commercial project. Habr is a mirror that reflects our desires. Not my personal desires or the desires of each individual visitor, but the totality of all our desires — the "average across the board." And Ivan Belokamentsov is the best at sensing what we all collectively need, and he delivers it to us.
Perhaps I wouldn't have written this article if I hadn't started watching the series "".
"We Lost God" (c)
This is from the series. And it's about us.
We have lost interest in the reality created by the Creator.
By God, Nature, the Big Bang — however you want to put it. Reality exists. Around us and independent of us.
We live in accordance with the laws of nature (God's design). We understand these laws (the design) and learn to use the reality in which we live to improve our lives further. We test our hypotheses through practice, discarding the incorrect ones and keeping the relevant ones. We interact with reality and change it.
And we have greatly succeeded in this.
There are many people on the planet. A lot, indeed. With today's productivity, we no longer need to survive— a minority can provide the majority with everything they need. The majority, however, needs something to occupy themselves with. Historically, the surplus resources allocated for creativity went to the most talented (or the most assertive, which is also a talent). Nowadays, there are so many free resources that anyone somewhat talented can access them, regardless of their level. Compare how many films are released globally each year and how many of them are watchable. How many books are written, and which of them are worth reading. How much information floods the internet, and what of it is genuinely useful.
Why is the profession of an IT specialist so popular? Because in IT, you can waste an endless amount of resources, and no one will bat an eye (just think of the year 2000 problem). In IT, you can spend years developing applications that will become obsolete before they are even launched, you can try to integrate incompatible components and somehow get them to work, you can reinvent the wheel time and again, or you can even spend your entire career maintaining programs in Fortran, which became obsolete 20 years ago. In IT, you can spend your whole life without achieving anything meaningful, and the most crucial thing is—no one will notice it! Not even you.
Very few of us will leave a mark in the IT industry. And even fewer will manage to leave a good memory behind. The results of our work will depreciate in the next 10-20 years at best, if not sooner. And, certainly, during our lifetime (if we make it to retirement age). We won’t be able to show our grandchildren the computer systems their grandfather worked on in his youth. People will simply forget their names. In the early days of my career, I operated mail servers under ""I have 20 years until retirement and 10 years until grandchildren, yet most of you have probably heard nothing about the "outstanding email application of the mid-90s" ("top email software package of the mid-1990s").
Perhaps in reality, we faintly realize the futility of our IT burdens, but subconsciously we strive to escape to where we feel comfortable. To imaginary worlds, where using Scrum and Agile invariably leads to products that conquer the world for decades with their utility. Where we are not just small cogs in big machines, but cogs without which big machines break down. Where our lives are not spent in meaningless execution of routine tasks, but are filled with creativity and creation, the results of which we can be proud of.
We escape to these beautiful, imagined worlds to flee from our own insignificance in the real world. We seek solace in them.
We seek solace, including on Habr. And Ivan provides it for us here.
Source: habr.com
