My brother sent over a question to Don and I on a coding problem he's having. Yes, most of my family members are geeks, thank you. You can probably blame that on my COBOL-coding mother.

In any case, his signature always contains this lovely quote from Brian Kernighan:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

That got me thinking about network topology and configuration and application delivery. Yes, most things get me thinking about that, thank you. You can probably blame ... well, no one. That's just the way I am.

But this tongue-in-cheek humor from Kernighan is just as applicable to network and application delivery architecture. If he were a network architect he'd probably use "troubleshooting" instead of "debugging" and "configuring" instead of "writing the code", but the core of the concept would remain the same: something is wrong and we have to find out what it is and it's really, really hard. I'm pretty sure this is where the idea of outsmarting yourself came from.

Troubleshooting a network is a daunting task. There's routers, switches, proxies, application delivery controllers, application servers, and databases. There's file servers, virtualization, and a plethora of other devices and systems through which every single packet flows just to answer a simple "Hi, are you there?" ICMP message.

Sometimes it's amazing anything works like we expect it to.

Diagramming out a network is one thing, deploying and configuring all the requisite devices that make up the core network and the application delivery network is another. And troubleshooting a problem in that complex a system is yet another.

And they talk about the horrors of debugging spaghetti code! Most network topologies end up, over time, looking like spaghetti, only network architects don't have a "step through, into, or over" option on their network analyzers.

A single, simple configuration error, omission, or mistake can result in hours or even days of digging through logs and network captures trying to figure out what's wrong. Although the "ah-ha!" moment (that precious moment in time when you figure out what is wrong and fix it, or you hit compile and the application runs as expected) is incredibly satisfying, but still we wish we didn't have to sludge through every trench to get there. One or two would suffice.

One of the ways in which we (as in F5) are trying to cut the time necessary to troubleshoot is to provide configuration and deployment advice that's already gone through the troubleshooting process - because we've already done a lot of the troubleshooting for you. The goal of an application ready network - whether it's for Oracle, Microsoft, BEA, or SAP applications - is to help cut down on the number of "gotchas" that invariably creep out of the network on the backs of gremlins and interfere with a successful application deployment. 

And we're working on making it even easier. But we'll talk about that later.