thirst and thrust

Refactoring in older systems is rarely just a technical issue. Most of the time a developer has to navigate organization and political issues as well.

Let’s say you are given small project that is low priority project to fix a bug in an existing application. The project is expected to have a quick turn around and was presented to you as trivial fix. You download the code and start to look at it only realizing that the code is a complete mess. As an example a single function on the system has 700+ lines of that does everything from making web service calls, parsing files, building SQL statements, executing those statements against the database, tons of redundant duplicate logic and SQL content, to name just a few issues. It’s so bad it makes your skin crawl.

You are stuck with a dilemma. Do you make the original requested fix without changing the bad code structure? Do you refactor the code to make it right? What if you discover that this one small problem is one that a number of applications in the company have? Do you propose a complete rewrite or heavy refactoring of code to make it cleaner and easier maintain in the future?

This dilemma is further compounded by management goals. The strategic direction of the company (or what the management says it is) will be effected by anything bigger than the original allotted time. Any alternative solution that would fix the bigger problem may cut into the delivery and (perceived) ROI of new development. This may affect the reputation of the managers or the team itself with upper management or customers.

This is all to say that the company has a bigger problem then the immediate issue. Weather they budget for it or not there is probably a lot of time and money being sunk into bad code. I have seen this in almost every job I have had. I can see the management side but I can also see that is the pattern continues a team (and the company) will become crippled by expensive maintenance.

Share on Facebook