Is code ever really old? What does old code even mean? Or is saying "that code is old" a form of temporal immunity? A statement implying that the statute of limitations has run out for the code to be qualitatively reviewed?
While adding a new feature recently, my colleagues had to enter a file that has been around for a while. They found themselves in the midst of trying to figure out what a method was doing so that they felt confident changing it to support the feature they were working on. The method looked like this pseudo-code:
It's over 300 lines long with nested if statements, multiple switch statements and yes, that comment was actually in there verbatim.
The developers mentioned that the comment was unhelpful in the Slack channel for our department and another developer responded: "Wow! Even old code isn't immune to critical scrutiny."
What Is Old?
I started thinking about that statement: old code. What does it mean? When that method was written, it was brand new. Code does not age while it sits idly in a version control system or runs on your server. The only time it ages, per se, is when a developer changes it. And unlike us humans, it can actually get worse OR better over time.
Furthermore - when you write some code, how likely are you to know how long it will live? In some cases, you may know that what you're doing is one-time throwaway code. I still wouldn't advocate writing it carelessly, but at least you know if you do, the potential risk is minimized. In all other cases, you should assume that the code you are writing is going to stick around in some form or another for a long time. And over long enough time, the chances of it needing to be changed will grow.
Code For The Maintainer
There is a slightly dark saying:
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
Or the much more upbeat version:
Always code in such a way that if someone a few notches junior picks up the code, they will take pleasure in reading and learning from it.
The point of both is the same. Always write your code with the future in mind. If you do that, it is much less likely that your code from the past will come back to bite you.
And, of course, if you're charged with making a change to old code, refactor voraciously. Keep your code forever young!