A smoooooth operation....

 Backward compatibility...

 

A word that I used to hear when I started my career. You design your APIs with backward compatibility in mind, don't break anything when you are upgrading, think about this, think about that etc.

Well, those teachings from my previous mentors didn't go in vain, as I made a fundamental change in how we report problems @ Gelato. 

 

You see recently @ Gelato, the CS (Customer Support) team moved from A ticketing management system to B ticketing management system, which is a monumental task for all the people involved in the CS team. Even though the fundamental concept remains the same the places, the attributes the concepts, and the naming of different attributes all change if you have this transition. And thus it was a big change for the whole company. 

 

After the decision was taken, the first step was to create a well-written transition document, which the good folks at the CS team tackled. Special thanks to Bartosz, Kyle and Anastasiia for this feat.

Next, it was time for the engineering team at CS to implement the same. 

 

The major challenge was to have minimal impact on the front-end side. We made maximum effort to keep the request and response body the same, as I mentioned earlier the business use cases and the concepts remain the same. Put simply, you have a title, content and attachments along with the category and sub-category of your problem and once you submit the request you should be able to see the ticket number along with the submission details that you need if there are any. But as for anything in tech, it is not a walk in the park, as there are some custom rules/logic we have setup that depends on ticketing management system A. This was an eye-opener and enabled us to implement it in such a way as to no longer tie your business logic with third-party tools that we use.

 

I was able to redefine this custom logic implementation with the help of my wonderful colleague Bartosz. Instead of hard coding the logic with custom fields, this time around we solved it by using flags, which does the same logic but now we don't need to keep track of the custom field IDs, which can change based on the environment workspace we use. 

We also took advantage of this transition to make things better for our agents, internal users and any future developers who come this way. Previously there was no development workspace and it was hard to test some features that needed, you know, testing. With the current ticketing tool, we were able to separate the fields that need separation based on environments, which helped the development team to test things freely without any hassle.

 

Thanks to my wonderful teammates @ Gelato, Karan and Nilesh, it was a joy working this transition rather than having a mild panic attack every time I refactor the codes, wondering where it breaks.

 

Well, let me come back to the title of this blog now. So what were the after-effects? 

Well, front front-end team didn't even need to make any changes to their wonderful front-end logic anymore. The mobile team @ Gelato did not need to rebuild the app and up a version, they simply, you know, use the same app to convey their concern to the CS team, which we can take care of on our new ticketing management system. So indeed it was as written by Sade, a smoooooooth operatorion

 

Life was all good.