Quick-fixing legacy code
August 16, 2007 | In Development |Today I had to make some changes to a piece of legacy code that I did not develop, written in .NET 1 C#. It made me think about where to draw the line between quick-fix-get-it-working and implementing a proper fix in someone else’s code.
This doesn’t really make much sense, so let me explain. The code is not particularly well written, it uses many hard-coded values and makes thinks more complicated than they need to be. The fix required me to edit a couple of functions to enable some front end changes. Now I know the code is badly written, so I instantly start to think about how I ought to rewrite it.
However, the problems that arise from this are:
- I don’t actually have the time to make these changes, never mind get involved in anything else.
- Where do you stop? This function, class, module…….
- Is it cost effective and efficient.
This last point, I suppose, is really the clincher here. Ultimately, no it is not cost effective or efficient to start refactoring someone else’s code where that is not the brief. The code functions on a live website, so there is always that danger of causing something else to stop working, particular as this code (as mentioned) is not great.
So I implemented the quick-fix-get-it-working solution. Which I think was totally appropriate here.