A Thought on Legacy Code

I’m quite sure that during one’s career as a software developer they may have the pleasure of maintaining legacy code. Of course, I personally define legacy code as a project that has absolutely no tests. Most of the time, though, this may be a fairly old project. If that developer has been in the career at least a couple of years, then one of the first things they may say to themselves about this type of project is how bad the code and/or the design is. I, myself, have also done this quite a few times.

However, something has occurred to me while I was updating, not one, but three of these types of projects. Indeed, there’s code in these that I still wonder who in their right mind would have written. At this point I had a sort of an epiphany: this wasn’t a bad thing, this is what helps to make me a better developer. The main reason I believe this is that, since I actually enjoy writing unit tests, I concentrate on making the code testable and write as many tests as I can. Only then will I proceed to make the requested enhancement or fix. The project is actually better for that and you just did something that someone else deemed or was just flat out told that they didn’t have time or the energy to do.

In conclusion to this small rant, don’t always hate on having to update legacy code. It can be to your best benefit as a developer and what you learn from that can last quite a while in your development career.

Using PowerShell to Help Debug Third Party Dependencies

Debugger Display using ToString()