05/24/2018 22:36:41

Over the course of my career, while my standards may have changed, I have always prided myself on the idea that the code I wrote was "solid" when judged by the standards of the day. Due to a recent job change, I found myself with yet another opportunity to validate this particular belief. Sadly, in this particular case, it appears to be a mixed bag at best.

Now let's be clear: This application works reasonably well. The bulk of the code was written about eight years ago. The application hasn't received any updates in over five years when I started working on it again last week. Despite this, it was still in service and providing value to my employer. That is a victory which brings a smile to my face.

But it's not all good news. Some parts of this application are absolutely terrible. For starters I made some poor technology choices. One example of this is choosing to use LINQ to SQL for the Data Access Layer. By the time I was done writing the bulk of this application, Microsoft had already released the Entity Framework as an upgrade. I probably should've taken the time to switch to that. Ironically I've now completely sworn off Entity Framework as I believe that writing your own SQL is the only way to ensure consistent database performance across anything but the smallest of applications. To put it in simpler terms: I prefer to use Dapper for the DAL and hand write all of my SQL code.

Another massive downside to my use of LINQ to SQL was the fact that I hadn't bothered to dispose of any of the Database Context objects I created. This of course created memory and database connection leaks which required that the application pool needed to be restarted from time to time. There is also no clean separation of concerns in the code base. For example: the data layer and the business layer are incestuously mingled together. In addition, I very much overused static methods in classes.

Let's not forget about my egregious use of ASP.NET WebForms. My goodness. This is one technology that I don't think I'll ever look back on fondly. But yes just like most other ASP.NET WebForm developers, I embedded way too much logic within the individual screens. On top of that I even went so far as to directly write LINQ to SQL queries within the screens. This of course will make rewriting the application as a ASP.NET Core application much more difficult as the process of separating and corralling the business logic and data layer will be tedious at best.

As you might have guessed, this application also makes use of the ASP.NET AJAX. For those of you not in the know, that technology was Microsoft's first attempt at making AJAX like functionality more accessible to the legions of ASP.NET WebForm developers who were content to pretend that they were actual web developers. Thankfully I was at least smart enough to restrict myself to a single update panel per screen thereby avoiding the very common nightmare scenario of screens with dozens of update panels. Yes, I've seen that scenario in other people's code more than once over the years.

Of course there are no unit tests. Hell, there isn't even one interface defined throughout the entire application. So as I've spent the last two weeks fixing bugs and adding features, testing for regressions has been extremely tedious and difficult due to the lack of tests and testable code.

It's not all bad though. The SQL Server database was fairly well designed and continues to do the job it was designed to do. The application still renders and works in modern browsers exactly as it did eight years ago. In addition there are some nice clever bits in the code that I can really appreciate even after all of these years. I can't make those claims about a lot of my earlier projects so in this respect, this code base marks a huge step forward for me as a developer.

At the end of the day I'm happy that this application was able to serve my employer so well for so long. I'm disappointed at some of my more egregious and embarrassing failures, but I'm in a good position to make amends as I'll soon be rewriting the application. This is particularly notable for me as I've never had an opportunity to revisit an older application that I wrote for a third party and rewrite it from scratch. I've revisited some of my older professional applications for the purposes of refurbishing, fixing and extending them but never once I have gotten the opportunity to rewrite them.

So I'm looking forward to seeing whether or not I can do better this time around. Will the technical decisions I make and code I write this time around stand the test of time? I sure hope so. But as with so many things, only time will tell.