The Virtues of Simplicity
I believe that simplicity and readability are extremely important in programming. In fact, I do not believe that this can be emphasized strongly enough.
To quote The Tao of Programming:
“Though a program be but three lines long, someday it will have to be maintained.”
All software ends up being revisited, particularly if you are doing something like pair programming. And as developers we almost always end up having to go back and look at something we wrote before, even if it’s just to exonerate our code against accusations of bugs.
I used to work at Lockheed Martin, and I wrote a library that would fire off explosive bolts used to deploy space craft parachutes, antennas, and release heat shields, etc. The code programmed several words worth of mask and command bits (which varied depending on the operation being performed) as well as a duration used to determine how long we would energize the pyrotechnics.
My first pass at writing the program resulted in a large amount of code, so I looked at it and got clever. I tried everything thing that I could do to make that block of code as minimal as possible while still retaining the original functionality.
I ultimately succeeded, and considered myself victorious. I moved on to other projects.
About a year later Lockheed started testing the pyro firing subsystem. And a few things didn’t work. So I was called in and participated in the testing. Once I saw what was happening I went back to my old pyro code and tried to figure out what might be going on.
Good lord, who wrote this ungodly indeciperable mess?
I ended up spending a considerable amount of time trying to understand how my code worked, and then even more time trying to figure out whether it actually worked or not (it sure didn’t look like it). The lone comment in the block of offending software “Fire explosive bolts” was ludicrous.
Eventually, by refactoring the code into something explicit and readable, and commenting the new code like crazy, I was able to understand my own code again, and could see what was happening.*
The experience was a powerful one for me. The process, known in some circles as “having to eat your own dog food” made me really think about how I write code and how I want it to look. I now try to be as explicit and simple in my code as I can be. I keep my functions small, so that it is easy to see what a function does at a glance. I use ludicriously long function and variable names so that it is easy to see what something is.
Time to go.
-Lee
*For those that are interested, it was an array over-run.