Last week I had to check a slow executing report. It was an SSRS 2016 report. I am not that familiar with the system so I took the task as a challenge. The execution time of the report was around 35 seconds. This time was very unrealistic based on the volume of the used dataset. My first task was to start removing queries one by one (and running the report) so I can catch a bad optimized one. Surprisingly there was no such a query. The queries were not perfectly optimized but not badly written. Also, it was interesting that…

A while ago, an ex-colleague of mine shared with me he had been given a task to refactor an enormous legacy MS SQL stored procedure. It was interesting to me how enthusiastic and happy he was without realizing the upcoming pain… Well, two weeks later the “refactor” was not even close to the final goal and management gave him another task because they had realized that this one is a lost cause. Is he a bad developer? Not at all! Only the approach for that refactoring was wrong. Let us recall what does “refactoring” mean? Refactoring is the change of the internal structures…

If we look into Wikipedia for code refactoring, we are going to see the following: “Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes) while preserving the functionality of the software.” Why code refactoring? Why do we care about improving the design, structure, and/or implementation of software? From the project manager’s point of view, the goal is to reduce the cost of support and future development. That is fine, but what makes the regular developer do refactoring?…