August 2014

Volume 29 Number 8

Don't Get Me Started : Unwritten Rules

David Platt | August 2014

The software industry, like modern society in general, is guided by many written rules, and it’s accumulating more all the time. But the older and wiserless stupid more cynical I get, the more I see that both society and the software industry are actually governed more by unwritten rules rather than written ones.

The written rule says: “Thou shalt not do X!” The unwritten rule says, “Yes, you can do X, at least under certain circumstances. You sort of have to in order to get the job done.” The former addresses the world as the writer wishes it were; the latter as it actually is.

Complicated? Sure. Nuanced? Definitely. Trouble? Often. But observe the next time an airline pilots or nurses union stages a work-to-rule job action instead of a strike. Without the lubrication of these unwritten rules, their workplaces quickly grind to a gridlocked halt. And so would society if we didn’t follow unwritten rules instead of written ones.

Consider Michael Pineda, the New York Yankees pitcher who In April received a 10-game suspension for using pine tar on his fingers to better grip the ball. The written rule says that pitchers can’t use pine tar or any other substance. The unwritten rule says that a little pine tar is OK in cold weather, as long as you’re discreet about it. Pineda was suspended not so much for using pine tar, but for doing it so blatantly that the umpires had to take notice (you can read about it at foxs.pt/1i3R3fz).

To take an example from our industry, object-oriented programmers have long declared global variables to be taboo. You should be shot for even thinking about them, right? On the other hand, what’s a class static, except for a global dressed up in wrappers to make it politically correct? Programmers often hang them from an object class named “Globals.” When there’s only one instance of something in a program, and it’s an integer, how many layers of abstraction and managers and services do you want me to wrap it up in to allow you to feel virtuous? As your blood pressure skyrockets from reading that last sentence, I’ll rephrase the question: How many layers are you willing to pay me for, when you could use that money for something else? Your check is your answer. And it’s probably different from your first reaction two sentences ago.

Sometimes the written rule consists solely of writing down the pre-existing unwritten rule. Hardwiring a string, such as a file name, directly into your code is usually a bad idea; but sometimes you have to do it. Give that construction a virtuous-sounding label and now you’re being good.

“We’re following the ‘Well Known Name’ design pattern,” says the geek. “Good, good,” says the non-technical boss. “I’m glad you’re using design patterns instead of that cowboy coding thing I’ve heard about.”

Guys, you’re hardwiring in a string. Do that when you need to, with your eyes wide open, when you’ve thought it out carefully and know that the benefits outweigh the costs. Soothe your uneasy feelings with the lie that you’ll come back and fix it someday when you get the time. But don’t think you’re changing what it does by dressing up its name. A bug hurts and angers your user no less when you call it an issue (see msdn.microsoft.com/magazine/ff955613).

Charting a course through these minefields, knowing when to follow the written rules and when to ignore them in favor of the unwritten ones, is what software engineering is about. There are few, absolute, “thou shalt not” rules in this business (although not scrolling a marquee string in your browser’s status bar comes darn close). The one thing I always tell my clients and students is, “Thou shalt think. If that’s hard, then thou shalt pay me to help you think.”

I’m curious to hear your favorite unwritten rules of software development—or anything else, for that matter. Send them to me at dave@rollthunder.com.

I’m sure that some pedantic geek will now say that because I’ve written some rules here, they aren’t unwritten any more. To which I reply: You’re breaking my unwritten rule against nit-picking your hyperbolic back-page columnist. That’s worth a 10-game suspension, don’t you think?

David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.