Raymond's Rules of IT

Rule #1: All users are idiots.

Rule #2: You are also a user.

Rule #3: All really good problems have multiple causality.

Rule #4: Follow the procedure, even if it is wrong.

Rule #5: If a more senior person gives an answer to a user, don't contradict; ask why off-line.

Rule #6: When a customer says that they will take responsibility for a server or application, if you would just provide it for them, they lie.

Rule #7: Creating a solution for today is creating a problem for tomorrow.




The Annotated Version

Rule #1: All users are idiots.

Any time you approach a user problem or problem report with the assumption that "they couldn't possibly have done x", you will rue the lost hours of troubleshooting you wasted. Always wiggle cables, confirm their password has not expired, and that sort of thing. And do your best to be kind to them, remembering that they don't mean to be that way. (Consider Hanlon's Razor.)

Rule #2: You are also a user.

Just because you have a technical understanding of hardware and software that is superior to the average person, that does not make you exempt from Rule #1. You will also from time to time make idiot mistakes. Deal humbly, therefore, with your users, and have someone check your work.

Rule #3: All really good problems have multiple causality.

Those problems which cannot be solved quickly and simply (a very small fraction) are usually the result of more than one thing having gone wrong, e.g. a missing error handler and a spilled Starbuck's. Do not, therefore, spend your time trying to find only one solution; implement a fixes which address part of the problem, one at a time, until you know you have it all.

Rule #4: Follow the procedure, even if it is wrong.

Yeah, yeah, I know. But here's the big picture: if you try various ways to fly by the seat of your pants, you'll never know how to undo what you've done when the correct steps are determined and approved, and all the work will have to be done from scratch. If everyone does something the way it is documented, it will be easy to write a script or something that will correct all of the fouled-up instances. (Also, it's better to follow the procedure, because then it is the procedure's fault that the result is wrong.)

Rule #5: If a more senior person gives an answer to a user, don't contradict; ask why off-line.

There are three reasons why this is important. (1) Oft times the real problem is political and not technical, and your senior person may be more familiar with that part of the back-story. (2) IT departments have very little power in an organization, but accomplish what good work they can through influence; and so it is important for the IT department to present a united front in order to maintain the credibility necessary to exert influence. (3) Sooner or later, that senior person will have input into decisions about your compensation, promotion, and assignments.

Rule #6: When a customer says that they will take responsibility for a server or application, if you would just provide it for them, they lie.

This is exactly parallel to the rule of parenting about children who want a kitten or a puppy and promise that they will do all of the care and feeding: the outcome of both is the same. Never, ever provide a customer with a server or application that you know is a bad idea and will be very difficult to maintain because, no matter what they say, it will come back to you--you will be responsible for cleaning out that litterbox long after the kid has moved out.

Rule #7: Creating a solution for today is creating a problem for tomorrow.

This paraphrase of famous statements by systems theorist Peter Senge and sci-fi writer Bruce Sterling is perhaps just an expansion of the well-known apohorism (sometimes attributed to Clare Booth Luce), "No good deed goes unpunished." Too often, someone in IT is just trying to solve a problem quickly and cheaply, and they fail to fully take into account the long-term implications of their solution. The less thought that is given to how a solution will be maintained or how it will impact other systems, the more likely that this solution will become a nasty problem to be solved a little further down the road. And the more the customer or boss swears that they don't care, that they just want it "out the door", the more you're guaranteed that the issue tomorrow will be urgent as well as annoying. Take the time to think it through and do it right.


© 2004-2021 Raymond Lockley