Developers: Think about consequences, implications, performance and related

Today I find myself removing a stored proc from our dbml because it is no longer in use. This stored proc updates the document information to be exported.

I check our source code and indeed no one uses it. So I go ahead and remove it. Is that the end of the story? Usually it is, but I decided to use a bit of common sense to find out if this is the last step or no. It wasn’t. Let me explain and get to the moral of the story quickly:

– We have a requirement to export the information of up to several tens of thousands of documents into Excel/Word/XML in a single go.

– We used to need to make sure that the document information is up to date, and given the source is in XML and XPath is rather slow, we built an intermediate SQL Server table to be able to have speedy exports.

– We made a change and now information is always up to date in the intermediate exports table, however the code that CHECKS if the information is up to date was not removed.

– So the info is not updated as it is already up to date, but we are still checking if we should ACTUALLY DO THE UPDATE. The code is still there.

What does this translate into? An unnecessary and performance degrading step. We need to check to determine if thousands of documents are up to date (and twice but this is another story) when they already are. This means there are two queries that we could easily avoid and save time as they add zero value but take several minutes to execute.

Moral of the story: when making a change don’t focus only on the change, focus also on the side effects of a change.

This should be a rule of common sense for all developers.