Evolution of Programming

Today I was working for an old customer, on code that was written a long time ago. For a point of reference, the code was sized to fit into an 800x600 resolution. When's the last time you saw a monitor that incapable?

Now they have a modern 4294967296x4294967296 monitor like everyone else, and it gives me a lot more room to make a mess. But for the most part I stick within the original framework.

But what strikes me most when I work on this code is the way it was written. It is in the good old state machine architecture, pre-event structure style, with an array of booleans driving a case structure putting a string on a shift register to select the next state and there are a dozen shift registers carrying all sorts of crap all over the place. All neatly packed into 480000 tiny little pixels.

The thing is that I used the shift registers religiously, like if there's any data in the program at all, it must be on a shift register. Of course, half of them are used in maybe one other state, and the mass of shift registers serves to confuse the issue more than clarify or assist.

It's always like this, it seems, when you look at old code. At least for me. Whenever I look back at something I did, sometimes even a few weeks ago, I often can see a better way to do it. I think this is a tick mark in the column for design and prototyping a concept with a first draft of code with the intention of rewriting it once you've finished. You can't do it all the time, but often times a little time and distance brings clarity. And clarity brings better code.