Really though, this question is perfect for a person like me. I am amongst the very small (and shrinking) group of people who started at their current company more than 1/2 of their life ago these days. Now narrow that to those people working in IT, and reduce that set even further to just include people who primarily write T-SQL code for a living.

We are a proud, but very small group. So small in fact, that the only meeting of this group I know if happens to meet at my house daily.

So not only do I know how some of my code has aged, I am constantly reminded of it. I think of it in different ways:

• How well the code was written in the first place
• If it is still in use
• If it can be/has been modified by someone else (or even you)

How it started

As a programming-focused person, your job is to create code that solves various problems. Business problems, administration problems, and everything in between. I have a terrible memory for so many things. Name, business processes, etc fall out of my brain as fast as I finish deploying the code. Not completely forget, but the details of the business are fading quickly.

What I remember is how I solved problems, especially with code. When I sit with some code I have written, I am transported to the time when I wrote it, and I start to feel the good, the bad, and the ugly about those times. Were these programs/data structures that we had enough time to do correctly? Did we do good enough testing? Comments explaining code that isn’t self-explanatory? Did I mean this to be a permanent solution? Was I skilled at this back then? (And did we have enough time to have done this better?)

All that information will help you answer the big question of this blog in a safer way than just looking at it and thinking, “This is terrible, so hence I must have been terrible.”

Is this code still in use?

This is where it gets complicated for someone who doesn’t change jobs much. You know what is still in use. You see every issue with every bit of code you wrote. When I started at my current company, I was a pretty new DBA. I was blessed with a lot of time to learn, and was pretty decent at writing T-SQL, but not great.

Many years ago, a few others and I designed a bunch of structures for an analytics solution. A few years after that, but still many, many years ago, we redesigned it and recreated it using this new SSIS tool instead of DTS. A few consultant friends who are still involved in the community were involved in the process through the years, too. But I wrote a lot of that code and designed the basis of those structures. And they are still in use today.

Not perfect, for many reasons that I won’t air here, but that code is still in use, many years later. We are actually in the process of building a third version, and I will admit it is time for a refresh since there are a lot of processes that have changed over the years that I have nothing to do with.

While I am proud of this code, it gives me feelings too. I know the good. We built a pretty strong platform for growth through the years. The bad. My other data architect and I were pretty green at dimensional modeling at the time, and mistakes were made. Still, the processes are still in use, and a lot of decisions have been made from our work. (Hopefully more good than bad!)

Has the code been modified

There is this thought that you want to become indispensable by creating things others can’t take care of without you. I disagree so very hard with this. You make yourself indispensable by making sure you are not the only person who can maintain the things you create.

Yeah, that sounds wrong, but if you can create useful things that keep you from creating more useful things, you are a treasure.

The business we all work with is constantly changing. The needs of your users are constantly changing. As an administrator, the platforms you support are constantly changing. Your code ages in a few ways, but being able to be maintained as change happens is one of the main ways I judge how my software has aged.

I already mentioned the data warehouse we created, and it has morphed many times, and held up well enough as the business has changed through the years. When we modernize it, remnants of that software will likely remain, but hopefully, all those mistakes we have made can be rectified. You are never going to create perfect code, but you will hopefully be able to create code that can stand up to the lifecycle of the business and not need to be constantly recreated (especially your data platform!)

My last example was from my early days doing administration. We had some issues with monitoring our servers, and there really weren’t a lot of monitoring tools out there (and they weren’t that affordable either.) So, I wrote some code to create SQL Agent jobs to monitor things like blocking, disk space, and such. I had just moved from Tennessee at the time, and so these monitors were somehow dubbed Hound Dogs. (IFKYK).

These processes have been around for over 20 years, and the patterns they were built on are still in use to supplement the monitoring tools that we use. The name has changed to WatchDogs, which is honestly a better name (my orange blood not withstanding). Plus, there are newer methods in use to find details as the DMVs keep getting better and better.

But to see the DNA of the original code used across so many versions of SQL Server is really kind of cool.

The takeaway

Code for others as you would have them code for you

I know that most people reading this haven’t worked at the same place for 10 years, much less 20 or 30. And the likelihood that you will is really, really quite low.

But if you want your code to age well, you need to believe that you will.

Even if you are a consultant who plans to be at a location for a few weeks, the code you write is your legacy. For most people, we have this fantasy that everything we create is and was great. I am 100% sure that the code I wrote at my first company is still 100% in use, as is. Even though we used SQL Server 1.0, and the many triggers I wrote only allowed you to update 1 row at a time. (Something I had been taught when I started to write the code, and didn’t learn was wrong until I had already left that company!)

My suggestion is that, as you are coding, think about what you want to happen when you meet a person who has maintained your code in the future. Like, say you are in line for lunch at a tech conference, and you meet this person, would they give you a fist bump? Or look the other way.