Kode Vicious: Permanence and Change

When you first write a piece of code how long do you plan to maintain it for? Are you more careful in writing a significant class versus a 100-line, throwaway script? It can’t be the case that every piece of code you write has to undergo the same process and the same level of scrutiny as every other, can it? Do you ever just leave a piece of code behind and let it fade into the past?

Fearing and Loathing Past Code

Back to Top

Dear Fearing and Loathing

I believe I am like other programmers in that there is plenty of code I’d like to forget. Unfortunately, although you can personally forget a piece of code, and at my age I have now forgotten more code than I’ve written—wait, is that possible? At any rate, although yes, you can forget old code, it never forgets you and thanks to the Internet many other people may be able to read what you’ve forgotten. If you’ve ever contributed to an open source project your code will probably never be lost, though perhaps it will be happily obscured by more recent checkins.

Having grown up with a mother who would make me redo my homework after saying, “Never time to do it right, always time to do it over.” I have more than a little bit of guilt associated with doing things right. Happily, I’ve since been able to work through some of the guilt but there is still a thin patina of it present in my soul that makes me care for each piece of code as if it is something someone else will someday read, and I don’t want them to be disappointed. My main goal is for the code to be good enough that even if, in 10 years, when I see the code again, I won’t find it lacking. I have not always achieved this goal.

Computer programmers and engineers are in a unique position when it comes to the work we do. We are both scientists, dealing in the abstractions that help us solve problems as well as craftspersons, turning those abstractions upon our modern lathes that help make the modern world what it is. When we craft our code well it works more effectively and more beautifully, helping to create better systems. When we rush the job, and ignore the nicks and scratches, the parts fail to fit and eventually we’re left with software that looks more like that fort you built in the backyard when you were a child. Sure, it was fun to hang out in that fort, but you ran back to the house at the first sign of a real rainstorm.

My favorite word in Japanese is ganbarimasu, , which is a single word that takes the place of the English phrase, “Do your best.” If someone at work admonished you to do your best you’d probably think them a bit odd. The Japanese say this to each other relatively frequently, and they take the admonishment seriously, whether they are sweeping a street, cooking food, building a house, or writing code. I admonish you to do the same with all your code.

When you make a practice of doing things right the first time, every time, it becomes easy and natural. So, yes, whether you’re writing a guidance system for an aircraft or a clean-up script for your mail folder, you should do your best. Someday someone else may need that code and you don’t want them to think your code is lacking, do you?

KV

Back to Top

Dear KV,

I was installing, or actually trying to install, some software the other day and was caught in this infinite loop of swapping software, hardware, and cables just to get one small thing to work. What a waste of time! There must be some way to avoid these types of loops.

Feeling Loopy

Back to Top

Dear Loopy

Clearly since you had time to write to me the loop wasn’t infinite, now was it? You know how to detect an infinite loop? Figure out how many times you’re willing to do the same thing without getting a different result and then stop after that many iterations! After all, insanity is often defined as doing the same thing over and over again but expecting a different result. You don’t want your coworkers to think you’re insane, unless, of course, you like sitting along at lunch. Still, there are better ways to convince people you’re out of your mind than repeating the same stupid process and getting nowhere.

What you describe makes you sound more like a changeineer than an engineer. What’s a changeineer? Usually this is the person they send out to a remote site, like a data center, when something breaks. They don’t really know how the system works or how to fix it, but they do know how to change every single component in a system until the problem magically disappears, at least for a few days. Disk is slow? Change the disk. That didn’t work? Upgrade the CPU. Still slow? Get faster RAM. Ad nauseam.

Changineer is a term I learned from some friends who work in a data center. Unsurprisingly I heard the term over drinks, at lunch—yes, it had been that kind of day. They see changineers every day, and learn to spot them and do away with them quickly so they can get problems solved instead of having them obscured by many random new components.

The thing you want to avoid is becoming a changeineer. Changineers use their hands, or worse, a text editor, while engineers use their heads. When you find yourself doing the same thing over and over and you’re still frustrated it’s time to walk away from the problem and think about it. Paper and pen or pencil are still the best for this, or perhaps a whiteboard. Write down the symptoms. Think about what could be causing the problem. Come up with a hypothesis—that is, a guess—about the real cause of the problem. Figure out how you would test your guess. Then test the guess. The process can also be repeated but unlike the process you described each change is preceded by careful thought. You’re a lot less likely to go on spinning around.

KV

Back to Top

Back to Top