Absorption in practice: life story

News about the purchase of IBM's Red Hat company has divided the public opinion. Many are reasonably alarmed about the future of Red Hat open source products; however, at least Mark Little, vice president of development at Red Hat, is optimistic about the future .

In one of the discussions, an experienced enterprise programmer Hank , who started programming under Commodore 64, shared a story about how the companies he was working at at that time experienced such changes. This story will be close to all those whose project has ever been absorbed or closed. The translation is published with the permission of the author.

In my life I went through several mergers. At first, most of the employees are shocked - after all, they had no idea about what was going on behind their backs. Then comes the disbelief that yesterday's competitors, department by department, become their colleagues.
')
After this comes the realization that now you are engaged in work that duplicates each other. You support two transaction engines, you support two certification servers, you support two ...

For the first couple of months, almost nothing will change - since the merger itself has yet to be carried out, and most likely not all contracts have been signed yet - but this idea will firmly sit in your head and will regularly remind yourself of an aching pain.

Then comes a sense of uncertainty. Suppose you are working on a transaction engine, and you are sure that it is better than its counterpart from former competitors - but will this product be further developed? A part of your colleagues behaves until irritation is relaxed - it turned out that they are working on a project for which there is no “double”. But your managers convince you: do not worry, nothing will happen to your product.

Meanwhile, seniors are beginning to leave. You still reassure yourself: "Seniors are leaving all the time." Yes, even if it sounds reasonable, but the fact remains: a lot of seniors are suspiciously leaving.

About six months later, small “riots” begin to flare up. The fact is that people want to know exactly where they are. But in the end, little is happening. More professionals leave.

A year later, an order comes from "their" headquarters: we will migrate to their platform. But we do not need to worry about this - because their platform is much better, and X, Y, Z, over which we have suffered all this time, they have already been made.

Over the next one and a half years after this event, you will write what could be called the most boring code on the whole Earth - a huge number of "connectors" that should temporarily connect the functionality of your platform with the other. All this is kept "on snot", because all the APIs that you have to use are internal, undocumented and full of omissions. Therefore, you have to visit their headquarters in order to communicate with developers about the component-bridge. The first thing you notice there will be the prevailing atmosphere of victory. Yes, they are winners, and you are losers. Your product will be eliminated, and their - to develop further.

Here you will also meet quite a few familiar people - those who once worked in the HR and marketing departments of your home company. All of them will be extremely interested in your client data transfer as soon as possible. You will see that they are being mastered with local systems, are exploring new tools for themselves, making plans about how to contact customers, follow the schedule - and keep track of how many customers have migrated and how many have yet to migrate.

Well, after you are waiting for the next "interesting job." The fact is that your company used product X to store customer data - however, product Y is used there. So please write a tool to export data ... oh yes, and do not forget that during the first year it should be bidirectional - for ensure that X and Y are synchronized until the migration of all customer data is complete.

So now for another year you will be working on another fragile connector, now between the two web APIs.

Of course, they will update their systems when they like it - for them everything in business happens as usual, including updating systems. However, each time in a similar case the connector will break, and someone will be very angry with you. The data migration process will be almost completed in about three years. Those HR and marketers who were most happy to help you with migration will be politely asked to “go out”. The amazement and refusal to believe what is happening on their faces will upset you, but at least you can still stay here, because you still need to engage in supporting the project that has now become legacy (even if technologically it is still ahead - despite the fact that it is directly above Nobody worked for them for about three years).

Instead of working on new interesting features, the whole next year you will be working on fixing bugs, which from time to time will be asked to fix the most conservative of your clients. You will watch your colleagues disappear one by one. Some of them will be transferred to headquarters to work on the winning project - but there will not be as many of them as you might think.

In the end, the last active client will switch to another product or go to another vendor, and your project will switch to a special legacy-support mode. He is still here, but now lives somewhere deep in the depths of the headquarters on a far-away server, which stands in a barely noticeable corridor in a closet hidden from the eyes of the uninitiated. The project budget is now approximately 16 hours per year - it is intended exactly to carry out CVE scanning from time to time.

Finally, this stage will come to an end. By this time, practically everything that remained from the original company would simply disappear.