In my current position, I am a .NET Developer that is part of a support team. I'm responsible for supporting brownfield applications used by the business. The applications range from Windows Forms to Web Forms to ASP.NET MVC applications, and I even have a CMS to support for the company's public-facing website. Soon, I'll have some WPF applications and web services handed off to me from the New Development team.
Now, I love greenfield development (who doesn't?), but this is a good opportunity for me to work on my debugging skills and my software archaeology skills. I even joked that my title should be changed to Software Archaeologist, since I am having to delve into poorly documented legacy applications and carefully sift through layers of code to understand what the original programmers were trying to accomplish.
I like writing good code.
And I do know that I can always improve. When I need to work on an application, I do my best to improve the code, and leave it in better shape than when I found it. Unfortunately, there are times when I can't and that truly pains me.
When should I be "okay" with writing bad code?
Ideally, never. However, I came to a realization or simply confronted an ugly reality: There are applications that I shouldn't clean up the code (except for bug fixes) and I can't take the time to write what I consider to be good code. Though I must state that what code I write, however bad, should be as bug-free as possible or what's the point?
How did I come to this awful conclusion?
I needed to update a point-of-sales Windows Form application. I scrolled through line after line of hard-coded values, and was constantly seeing other instances of bad code smell spread throughout the program. Some of these hard-coded values were rules for the application (i.e. if store has this rule, then allow this function.) Changing any of these required a rebuild and deployment of the application. Why weren't these types of values placed in a config file that could be updated via a text editor and deployed? How in the world would we know what a rule number meant if we lost the database? I could spend months on fixing all the issues that I considered to be wrong.
The Application has an expiration date.
That fact changed everything - I still didn't like it. I can't spend valuable development time correcting and changing code that I believe needs attention. I can't take the time to write code that is going to be maintainable for years to come. The application isn't going to live that long. A newer version is coming down the pipeline.
I still struggle.
I do my best to avoid writing bad code as much as possible. I keep maintainability in mind when I am writing code. For those legacy applications that have a short lifespan, I write code that is "good enough" to correct the bug or add the required functionality. And I definitely aim to do no harm when I have to write that less-than-ideal code.
The trials and ramblings of a software developer trying to fix himself.
