Revisiting the old code (or not)

This blog is becoming more a collection of mistakes I’ve made than anything else, but I believe learning from other people’s mistakes is important. So each time I do something not-so-smart, I am sharing it here.

I was not sure how to call this post, and still not sure the name reflects the contents, so let me proceed to the story:). It has been over a year since I’ve started to rewrite the pieces of an old system, one by one. And granted in the very beginning I didn’t know the data so well, so after a year in production I could rewrite most of them much better.

But what is more important, that data itself has changed as well. One of the important changes was that a year ago we were using two external service providers for loans processing, and now for several months we are not using one of them (except of the servicing of the old loans). But it turned out, that I had a step in my code (which BTW had to be executed every two hours!) which would try to fill in the ID from this old system which we are not using anymore – for all records, which do not have this ID assigned! Which means, (since we do not use this system) that every two hours I was scanning all records – for nothing!

After I commented out this loop, the execution time for the whole process became pretty much invisible.

… now – how I should title this post?!


Filed under Data management, Development and testing

2 responses to “Revisiting the old code (or not)

  1. william h berger

    Hi Henrietta!

    This is a maintenance effort that SHOULD be performed when business processes change. And what you did is called pruning. So, I would call the post PRUNING FOR EFFICIENCY or PROCESS CHANGE AND PRUNING…

    You know how I think your back-end work is… it’s meticulous and effective. And naturally, you have cultivated a work process that incorporates the acts of code review, maintenance, and refactoring. Unfortunately, this is NOT the norm. It’s good to see when you post things like this as an example for others. It would be good if you could also quantify the impact your work has on the business. This would help others who see and read your great tips, to convince their bosses to let them do this kind of work as well.

    Great job!

  2. Henrietta Dombrovskaya

    Bill, thank you so much for your comment! I really appreciate your feedback – always. I agree that it is very important to quantify the impact of this kind of improvements, because most of the time the projects which are marked as “internal” in the JIRA tickets, are completely invisible to the end users and/or business. And I love the situations when I can confidently say, how much money I’ve saved for my company:)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s