Critical Decision of Re-Writing a Wheel!

I have been in cross-roads – when the officially supported libraries are not in the language in which our app is coded. Have you? Did you re-write it or did you use it as it is?

I had both good and bad experience with that however, with enough experience, I can distinguish why it was good and why it was bad.

The Bad

Officially supported library was in Node. However, we only had at that moment expertise in PHP. We went ahead and coded a library full of YAML in PHP. Our app became popular, and we just couldn’t scale without giving heavy cost for servers! We accepted PHP is there because it is too big to kill.

The Bad in Good

Officially supported library was in Node again. This time we re-coded it in Go. We were using in node as the usage was vast and it would take us three months at least to rewrite before we even began to use it. In Go, immediately we were able to reduce the servers and then most of the errors/bugs were caught in compile time. Yet it wasn’t worth it at all since server cost saved was nothing comparison to manpower we have put to keep it updated and retaining these talents!

The Good

Officially supported library was in PHP. We were already burnt once so shying away to use it. We wrote it – it took us little over 2 months. Damn, you have to write a lot in Go. Obviously we had reduced server cost a lot but since app demanded almost real time updates, we were able to pull it off without a lot of overheads like Redis and RabbitMQ.

Our conclusion

As long as language is multi threaded we will be better off using it. If not, re-write it.

Worth Sharing?

F`k it – Fix it – Psychology

I have just created a page Hire Me and told few friends and one asked me to come over and discuss a few projects his team is working where I can assist. Every single one of them was in Dot Net except one in Go. He is helping a renowned trader who has chosen to stay anonymous. A project is having code name OTAMIA.

Too Hot to Touch!

He stated that because of some inconsistency in an official Client of Kite Connect, the project is becoming annoying and unnecessary harder. His approach was not to touch the official API but use some duplicate structures to fix the issue or some conversions. He didn’t touch the official code but then again it wasn’t new. I created a framework on which every single Shopify App was build in SpiceGems and there, everyone worked on the framework decided not to touch what I wrote and this made a huge pain for everyone. I asked them why – they just said it is official (part of a framework)! My response was ‘F`k it Fix it’

F`k it – Fix it

The whole job of mine is to save time and pain. So we fixed the following issues or added feature (so far)

  1. Turned two packages into single – R.I.P compatibility.
  2. This enabled us to use a single structure for both packages.
  3. The error was coming as nil even when there was one – we fixed it.
  4. Data in converting JSON to STRUCT was giving blank (0000-00-000) dates – we added another known date format.
  5. We added a new flag to enable OI to be fetched.

All of the above changes were made within 2 hours but this removed all the unnecessary conversion, custom structure for proper JSON conversion and managing time column in our project. All of this so far had taken more than a week.

Be Brutal – Consultant’s Principal

Coding must be enjoyable and just because something is coming under the tag “Official” it doesn’t mean that there is no scope of improvement or you got to use that in the same way. If I can tell my team to f’k my framework, I can tell to f’k anyone’s. Knowledge and Tech both are evolving and we are all learning. Wherever you can save time and pain – just go ahead. Although, sometimes initial pain would save a lot of pain and time in the future. You will have to make a wise choice.

Open-Source KiteAPI

It was almost impossible for my client to let us make it opensource but he agreed and we have a code over here under MIT license.

https://github.com/VarunBatraIT/kiteapi

Worth Sharing?