The moment of truth: When new eyes meet old code

Have you ever churned out fairly extensive code, then returned to it many years later? Did you like what you saw?

As a preface, I should mention that this post is primarily aimed at admin coders rather than full-time developers. If you work inside an IDE for eight-plus hours a day, then some of this might be a bit off the mark. Then again, exists for a reason.

I've had occasion to revisit my own, elderly code quite often. Sometimes I clearly recall how I originally designed it, and some or all of the reasoning behind some of those decisions. Other times -- usually on smaller projects -- I can't remember even writing the code, and I run into elements that have me scratching my head and wondering what I was thinking. Usually, in those cases, I start to rewrite the stranger parts until I come across the same blocking problem that produced the odd code in the first place, and I revert everything to the original.

[ Also on InfoWorld: Why admins should know how to code | Get practical IT advice and insight with Matt Prigge's Information Overload blog. | Get the latest on data center hardware and software with InfoWorld's Data Center newsletter. ]

But a different thought process occurs when you hand over code to someone else, especially when you were the sole developer of said code. In the open source world, this is the way everything works, so code inspection is available to anyone who wants to take a look. However, when we're talking about internal data reconciliation scripts, database-backed data collection apps, and the myriad Perl/Python/PHP/whatever glue that holds an infrastructure together, it's a horse of a different color.

The first time someone else's eyes work their way through your 1,000 lines of Perl that handle some precarious database import/export tasks every night, it can make you feel like a kid who hasn't cleaned their room. Frankly, it makes you wish you'd added about twice as many comments. (Note: This is true even if it's you revisiting your old code.)

The fact of the matter is that it's not necessarily poor coding that can raise eyebrows in these cases; many times, it's a product of the age of the code itself. As time wears on and coding languages change, adapt, update, and provide completely new methods of accomplishing certain tasks, old code seems crusty and antiquated, and somehow this can rub off on the original author.

It can be little things, like a PHP script written before PHP 5 that does lots of file manipulation, yet doesn't use file_put_contents anywhere, because that was introduced in PHP 5. Or perhaps an even older script that was written before the world knew array_push(). Of course archaic scripts by themselves do not indicate poor coding, but when viewed through the lens of today, they're like watching silent movies.

Other than resolving to provide clear and plentiful comments and structuring our code as cleanly and portably as possible, there's nothing to be done about this phenomenon. It just is, and it always will be.

In a software development shop, many eyes usually focus on all of the code checked in every day, and there's plentiful interaction between developers. In the gray area of internal infrastructure-specific code, it's not uncommon for beefy scripts to be completely untouched by source code version control, and many times that code is written and tended by the same person throughout its lifecycle. If that person moves on to another job, someone else has to parse through what might be years of changes and adaptations of what was once a small script, but now has become an integral part of the overall puzzle. Alternatively, nobody takes it over -- or worse, nobody even knows about it -- and it becomes a zombie.

Admin coders occupy a gray area of IT, as we're not really developers, yet we wind up writing a lot of code to address issues that shouldn't or can't be solved using readily available tools. If we're doing things right, we'll continue to learn and improve our coding skills as time goes on, and we'll revisit old code when the need arises and take the time to modernize it. We're better coders today than we were last week, and we might be just a bit better next week than we are right now. That's the idea, anyway.

This story, "The moment of truth: When new eyes meet old code," was originally published at Read more of Paul Venezia's The Deep End blog at For the latest business technology news, follow on Twitter.