Main Content RSS FeedFeature Article

Stop Signs vs. Stop Lights »

Sitting in traffic today I realized that teams of people are either like stop lights or four-way stop signs.

Stop lights are nice because everybody knows the rules, and they aren’t flexible. Everybody knows what everybody else should be doing, which is either sitting there idling, burning expensive fuel, or driving forward full-blast. Big queues build up sometimes behind a stop light, blocking other streets. When the stop lights aren’t timed perfectly (and they rarely are) you get these gobs of cars hurrying, then waiting, then hurrying again. One thing is true, though: that clueless guy talking on his cell phone doesn’t mess things up too much. Even they can figure out when to go.

Stop signs are different, especially the four-way kind. Your driving instructor told you that things move around to the right, but in practice there are tons of shortcuts, simple optimizations people make. Like if the fellow across from you is going straight you can, too, at the same time. Or being able to turn right, out of order. If you’re waiting for your turn at the game you keep moving steadily forward, always advancing. When you get to the game, though, you find that things are very fluid, and you had better know what you’re doing or you’ll mess it up for everybody. That clueless guy on his cell phone screws up the whole system, though, requiring heroism from others to get things back to normal.

Seems to me that’s exactly like most teams. Lots of teams start out as a stop sign, but eventually they get someone who is the equivalent of a cell phone idiot, not paying attention to their job, messing it up for everybody. So it takes a hero to fix things that cell phone idiot breaks, but eventually the hero can’t keep up, and management puts in a stop light. Lots of rules, lots of forced latency, and very little flexibility forcing everybody else down to cell phone idiot’s level, a lowest common denominator. The strangest thing is that “stop lights” get labeled as progress. Managers pat each other on the back for the standardization, the procedural improvements, etc. when all they really did was encourage universal mediocrity by not removing the cell phone idiot from the team. Congratulations, you crippled your team and kept substandard employees! Real progress would be if teams took down the stop signs altogether, by finding and removing delays.

It’s been years since I’ve seen a yield sign, or an intersection without a sign at all. I miss them.

>> Comments | ShareThis

Main Content RSS FeedRecent Articles

Happy 150th, Minnesota »

Minnesota, the land of my youth, is 150 years old today, having been admitted to the Union as the 32nd state on May 11, 1858. Happy birthday!

>> Comments | ShareThis

links for 2008-05-11 »

>> Comments | ShareThis

Dell TOE Key »

I had the opportunity/task today of replacing a Dell PowerEdge 1950 system board. A voltage regulator was dying and taking the machine with it. I hadn’t actually seen one of their integrated TCP Offload Engine keys before, and they’re interesting, if not a bit small. Go RJ11!

Dell TOE Key out of a PowerEdge 1950

Dell TOE Key in a PowerEdge 1950

Personally, I like bigger parts, so when they fall on the floor I can find them again. Not that I ever drop anything. Nope. Never.

>> Comments | ShareThis

links for 2008-05-07 »

>> Comments | ShareThis

links for 2008-05-03 »

>> Comments | ShareThis

How is /etc/hosts bad? Let me count the ways. »

/etc/hosts is a nice way to temporarily convince a host that certain DNS mappings exist, for testing, troubleshooting, or just temporarily working around oddities. However, I’ve seen a resurgence in using /etc/hosts for more than just temporary purposes. This, in my opinion, is bad.

I’ve always been a huge fan of tip #6 in “The Pragmatic Programmer:” Don’t Repeat Yourself. As soon as you repeat yourself you risk the different copies getting out of sync, which causes problems and confusion. Putting a fully-qualified domain name (FQDN) in /etc/hosts as well as in DNS means that at some point later in life the two will be out of sync.

“It’s only on a couple of hosts, for testing.”

First, if it’s on more than one host you are repeating yourself. Second, testing is fine but now it’s another thing to remember to fix when you roll into production. It also means that production will potentially be different than your test environment.

“We don’t need to put this in DNS.”

Why not? DNS is a database built to solve the host name to IP mapping problem and it’s good at it. Perhaps you have more of a political problem with whoever runs your DNS.

“You have automated tools that can maintain synchronized copies of /etc/hosts on multiple machines, so what’s the big deal?”

Just because we can doesn’t mean we should. Plus, you’re still repeating yourself. The machines can still get out of sync with each other and/or with DNS.

“If we don’t put this in DNS then it won’t get hacked.”

I’m pretty sure hackers know how to use IP addresses. This is security through obscurity, which doesn’t work.

“Well, they won’t know that the server is our database/app/web server if they can’t resolve the name.”

A quality port scanner can often tell what services are on what ports, even if you are running services on non-standard ports. In short, if you are relying on the lack of DNS to prevent hacking you’re in trouble.

If you really want you can use ACLs in BIND to restrict who can query certain DNS zones.

“I want entries in /etc/hosts for performance reasons.”

A caching name server on the host may also increase performance and still get its information from DNS, which does not violate the don’t-repeat-yourself clause.

“I want entries in /etc/hosts for reliability reasons.”

Again, perhaps a caching name server locally would fix the problem. And if you have unreliable DNS you are probably having other problems, too. Perhaps you should fix that.

“DNS is tricky to administer, and the files are simpler.”

Maybe, but if you have a service, application, or system that needs DNS entries you should probably figure it out. Eventually you’ll have to know something about DNS. Editing files is simple until you get more than one server, and then the effort to keep the hosts files synchronized is usually better spent keeping DNS up to date.

“We define host names to have different IPs using /etc/hosts, which is how we do load balancing.”

You can do the same thing with round-robin DNS entries.

“We define host names to have different IPs, based on the functionality the server needs. So ‘database’ is 192.168.10.20 if it only reads and 192.168.10.21 if it needs to write.”

That sounds very confusing. Perhaps you could just register ‘database-read’ and ‘database-write’ in DNS and teach your app which one to use?

“Hosts files are a proven, reliable technology.”

*sigh* So is DNS…

>> Comments | ShareThis

Voicemail Message Etiquette »

I just cleared out my voice mail box, and I made some observations about voice mail messages:

  • First, I hate voice mail. Email me instead.
  • You don’t have to tell me what time it is. Voice mail is time-stamped, and it usually doesn’t matter that much.
  • You do need to say who you are, because voice mail doesn’t record that. Do this in your first sentence. If you are with a vendor you should say that, too, especially if I’m waiting for a call from you.
  • Please use your full name. You might be one of my closest friends but sometimes phones make people sound weird, cell phones cut out, and background noise sometimes makes it hard to figure out which “Bob” you are.
  • If you called to have a conversation with me just tell me to call you back. A conversation is where two people talk to each other. My voice mail is not me, so you’re just talking. Talking != a conversation.
  • Tell me why you called, using one sentence or less. Extra points if the whole message is a sentence or less.
  • Tell me where you want me to call you back. Don’t assume my phone or voicemail has a log of your missed call, though if you’re sure I have your number it’s fine to tell me to call your cell, etc.
  • Don’t leave me a message saying only that you’re going to try calling me somewhere else. Not useful.
  • If the message includes an address or a phone number say it twice, slowly, so I can write it down. The first time you say the phone number I’ll be scrambling for a notepad, and replaying the message just for a missed number sucks.

That’s about it. *Seems* simple. Thanks for listening. :-)

>> Comments | ShareThis
Close
Powered by ShareThis