Refactoring your code regardless of the platform

I just had an interesting opportunity to learn of a certain situation where memory was the crux of the problem. I was not on my toes and realized after the meeting, "was refactoring your code an option?"

 

Yes, I have no idea where they were coming from since I could not see the applications nor know the configuration conditions, yet I have had constraints on my platforms hinder my applications and it crushed me in my younger years and into my late 30's, and a few odd times in my 40's.

 

The conditions were pretty basic yet then again, you never know what the data might hold, and it could suprise you. I recall my colleague, awesome developer, some 30+ years, 15+ years in high frequency trading, and I was working on his ETL issues, and noticed the data schema changed a few years back, and he was looking back across 5-7 years, and in the midst of that, two columns of data switched out of 40 columns in a 1GB data set. Yes, it was the major columns too, price and volume, major data items. He would have never seen it unless another set of eyes was looking at the error and rejection rates and logs of the data transfer migration. I was showed him what I found and he smirked and said, uh-oh, and we fixed it, and reran everything and I had him make a note to watch his error logs more closely if I were not around.

 

Of course, he looked at me with a smile and knew I knew what he knew and he was my master-sensei in so many ways. We continued on. His programming skills were 10x better than mine, yet his experiences were at only one layer, the application layer, and for me, I had to deal with the entire ISO TCP stack. We made a great team. For me, he looked at my coding system and smiled, then saw how rugged and strong mine was, took it, and polished it. We were like miners. I found and dug up the diamonds and dusted them off, and he would take them, sort them, and polish them. A great duo - batman and robin like. Good times.

 

Years later, we did refactor his code and moved it to the cloud. Because of the confidentiality of the code, we outsourced it into 4 different sections, sort of like the Manhattan Project, no one team knew what the other had, and what they were doing. It came back together nicely and 10 years worth of refactoring improvements to boot. Good stuff.!!

 

So, back t the issue - auto growth, auto scaling to deal with not enough resources like memory, not enough I/O, not enough disk space in temp or log space, what have you. What do you do? For me, I realized the auto- whatever could be costly if not predicted and managed carefully. No one wants a surprise utility bill at the end of the month. Well, my colleague mentioned tuning and for me, I realized that too, yet I was in the midst of compiler options and just basic code refactoring yet that word did not come to might right away. In fact, for me, not knowing the history of the application, I realized form, fit and function had to be addressed, and isolation versus resource shaing - and for me it was more like architecture design review, code walking, code review. Not everyone writes functions and code the same. (note: later on, I realized, system.gc() would be a good question to consider for which I had to deal with this in not locking up a processor or ram in a heavy lift condition of some production run and formulation.)

 

This gentleman was more than 15 years in their venue and for me, I was like the same in integrated variations of all kinds. A fresh look with fresh eyes, ears and heart might help. He was cool. I liked that. Like I mentioned, there are so many applications and yet, they are all basically the same. I/O. bits and bytes. from the node room to the board room, that was my motto.

 

Regardless, in the last 20-30 years, I have only had to refactor my code 3-5 times and it was actually a good problem to resolve. I actually made the code work faster and better because of fate.

 

Well, to make a long story short - when you are in support and supporting a devops team, you might realize that your suggestion and experience might have to come across as a nice nonchalant suggestion because some personalities might want you to mind your own business.

 

That's the challenge. Development and Support are hand-in-hand and the priorities of one is not necessarily the priorities of the other, yet the mission of the company is one in the same.

 

Remember, keep  your cool. Do your job, don't worry. No one is going to die. Just remember, we are a team and some people might be keen to contribute and a lean budget while others need to be released.

 

We need great team members and those who believe in the mission and will stick with it. Just believe.

 

more to come...