Hawk Software

If you have programmed for any amount of time at all, you have experienced it.  You need to modify some of your old code. Maybe it is a few months old, maybe even a few years old.  But as soon as you begin to try to parse it you wonder “Why did I do it this way?”, and “How does this slop even work?”  Time may heal a broken heart, but why does it alter our perception of our old code so much?

It’s true: the older your code gets, the more foreign it becomes.  It gets so bad that some of my 10+ year old DOS code might as well as been written by a stranger, except it has my name on it!  Some of that, of course, is that technology has changed; who needs to write VESA graphics routines nowadays?  And with multi-gigahertz multi-core CPUs the norm, how many programmers REALLY need to use inlined assembly to speed up C/C++ code?  But the other part is that I have changed also.

Most programmers, like myself, love to constantly learn new things, and experience new challenges.  Back when HawkNL was just beginning (actually, it was OpenNL back then, but that is another story…) I immersed myself into socket programming, which was relatively new to me.  HawkNL has held up well during my programming hiatus while I built a home,  changed careers at Caltrans, moved my family to a new city, and many other things too personal to include here.  While I may not have been programming, I have continued to read articles from magazines like Dr. Dobbs Journal, Software Test & Performance Magazine, Game Developer Magazine, and other magazines and on-line resources.

But now as I work on the framework of HawkNL 2.0, I look at my past code and wonder why I would ever do things that way.  For example, when writing portable code, I strongly believe I should keep platform specific code contained in as few files as possible.  Ideally, all platform specific code should be in a separate source and header file, or better yet just a single header file.  But instead I included platform specific code in multiple source and header files, which makes porting to new platforms harder and more error prone.

The more code you produce, and the more code of others you look over, the more focused you own idea of good code becomes.  And code you thought was very good in the past is now no longer as good.  You see all those little warts, like formatting which is not the same as you now use, or different variable naming conventions, or code that obviously should be re-factored.  Or code that, even with the comments, you cannot figure out how it works, or believe it even works!

But on the end, this is a GOOD thing, don’t you agree?  Because it means we are becoming better programmers by knowing how to write better code, and better code should be our top priority, even above cool new features.  Users would be REALLY upset if we wrote poor code that, hypothetically,  allowed a virus to be installed just by browsing to a malicious web page, right Microsoft?