Next year we are getting some data from a new source. I was tasked with making sure that programs which depend on this data use the new source. No problem. I knew where the old data got stored. I pointed the code to this previoius position. And I shipped the code.
Our customer has an acceptance team which tries to test everything. They told me my code was not working as expected. I checked it out and found that they were right. So I traced the problem back to the database. It looks like the new data was getting put into a new place. That couldn't be right.
I asked around and found that the new source named the data a little different. Therefore new elements were created in the database. I was referencing the old elements. But I told them that it was just a new way to get the same data. It should go in the same tables and columns.
Then I realized the error of my ways. You should trust nothing. Even the obvious will not be obvious to all. I spent about a week going over options on how to fix this. We needed buy in from the customer since it was late in the development cycle. Luckily the command decision was for those upstream guys would put the data in the expected columns. Whew.
The decision by the stakeholders meant I did not have to change my code. Next time I will validate all my assumptions, even the silly ones.
Mysterious Double Instance Hampering Performance - I study the existing code base. Confer with a colleague. Then I determine the optimal plan to change the functionality to load only a slice of all the dat...