IntegrAll

We all (engineers) once in a while have the opportunity to become technological scavengers. It happens that a partner's particular technology has not been upgraded in a long time, despite it being actively maintained and developed by the vendor. At a certain point, technological debt might be impossible (or close to impossible) to catch up. Due to the business importance of a solution to a partner, you might get stuck in some legacy code, constantly trying to patch more and more exploding issues, just like many others before you… I have been there, but I found a solution, how I could walk the partner through their problematic front-end upgrade process without intervening significantly with the current thing.

IntegrAll is a great example of how the old could play along with the new, how engagement could break stereotypes, and how hiring the wrong management could cost you a pile of cash thrown into trash…

How it all started

Let me pick up from getting stuck in a legacy code thing… Back then, I was working with an automotive business company. They had this old monolithic application with a Backbone front-end and loads of bugs lying down in Jira for ages. Not long after joining the project and proving my performance, I have been "rewarded" with unlimited overtime (to be used per needs) and eventually a work package, which meant that I was doing x1,5 my work time for the agreed period. Delivery management decided to go with this to deal with their "Jira hiccup" problem. Few days after the work package launch, most of the crucial work has been done, and I got the feeling I am being overpaid comparing to the initial purpose of the offer. I went to the delivery manager, presented my progress, and shared the idea of further steps we could take as delivery, to make something significant to the project. The DM (according to his own words) needed a "fresh blood and proactive approach" on the project, so here I was. I also pointed out at least a few risks I noticed while working with the code (for example, possible problems with pre-release merges, that six months later turned out be impossible to perform considering wrong project structure, shared between different teams working "independently" on functionalities, actually interfering with each other when it came to merges - ouch...), and solutions to prevent or mitigate them. I got a green light to go with my ideas, but months later, I realized he did not understand a thing from our multiple conversations, updates, and 1-on-1s.

The solution

Problems I diagnosed around my partner's technology were severe, and I like to handle things proactively, not reactively. As I had some spare time and felt my partner deserved more for what they have been paying, I started to work on something that a bit later become IntegrAll. The idea was simple – I had this old, buggy Backbone front-end that partner needed to be refreshed, and before I joined the project, some attempts have already been made. The main part of the old interface displaying the actual search results and content from the system got replaced with an iframe, pointing to a new partial interface written in VueJS. However, the integration has been implemented in a very hard way, which required the developer to manually modify the Backbone's views. It became an excessively complex solution considering the goal. The goal was to slowly migrate to a new solution while replacing parts of the old one. It was not to end up with two solutions required to be actively developed and maintained.

The basic idea was just fine, but I had to find a way to integrate the two to gain more control over the old solution – from the new one. The answer turned out to be pretty simple. I have prepared a plugin for Backbone, attempting to load a new solution within an initially hidden iframe. If the IntegrAll app was available, the plugin then shared a high-level object containing all of the important legacy solution's functions. Having access to this object from the new application, I was able to modify old solutions behavior in runtime by overriding Backbone's functions' prototypes, which virtually gave me total control over the legacy thing, without modifying a line of its code (outside of the plugin). If the difference is not yet clear to you compared to the previous integration, I will shed some light on the issue for you. Previous implementation required to modify Backbone views persistently. The new one allows overwriting the render function prototype, not the view itself, which also means that if the new application is by any chance not available, we get the full and unchanged functionality of the old solution. Simple and working.

How did it end

Technically and for me? Perfect. For partner – not sure. I got the whole thing done right before the Covid-19 pandemic strike and never got back to the project afterward. The plugin has been released to production just a week earlier. I performed hours of knowledge sharing sessions before leaving, prepared documentation, but this project will probably die as I heard. Allegedly, the incompetent delivery manager keeps saying that there is no knowledge about the solution, etc. Still, if he listened closely to the messages I have been passing him together with my deliveries for months, he would know that they do have everything they need (including people who were watching me making the IntegrAll), to simply use the solution for their needs, without much additional effort. As I know how much my time costs, I would consider it a huge waste of resources if the partner eventually allows the manager to dump the ready project (due to the manager having more co-managers than developers - why would he need them?). Instead, the manager should be dumped for all the unethical games he has played with subordinates, and for violation of his employer's code of conduct. In my opinion, such behaviors compromise and disqualify one in charge of people from being in control. Knowing the partner's needs, I am 100% positive that the prepared solution was the best I could achieve in harmony with their way, so without drastically rewriting the whole thing. Anyway, this will probably remain the biggest yet the most satisfying over-delivery in my professional career.