In theory…

I don’t normally peruse the reviews of my books — while I appreciate well thought out criticism, I normally find personal notes from folks who’ve read my books more profitable for mining out where I’m falling down on the job as a writer than reviews posted on book seller or book review sites. But one specific book review caught my eye the other day that I think points to a larger issue in the world of engineering, especially network engineering. The reviewer stated, in essence, that there was not enough practical application in my more recent tomes, and that I’m covering the same information over and over again.

Let me begin here — I’m not writing this as a defense of my own writing so much as to think through a habit of mind I think doesn’t really help us as an engineering community.

As far as the facts on the ground go, the reviewer is right on both counts, and wrong on both counts. Let’s imagine, for a moment, that you want to understand how a car works. You approach three different people — one a race car driver, another a top flight mechanic, and another an engineer who designs engines. Are any of these three going to give you the same answer to the question, “how does a car work?” And yet, are any of them likely to be “wrong?”

We, as network engineers, tend to be the mechanic, while letting the folks building applications be the driver, and letting someone else (we’re often not quite certain who, but it’s probably related to the IETF in some way) be the engineer who designs the engine. What I’m finding out, now that I’ve been in the networking engineering field for almost 20 years (I started Cisco TAC in 1996), across my years in a lot of different engineering positions (from TAC to Escalation to IETF participant to ISOC to certifications to coding to…) is this simple point —

Theory and practice should be complimentary, rather than orthogonal.

In my earlier books, I wrote about configuration and practical, hands on deployment — partly because that’s where I was, and partly because that’s where the networking industry was. I still think understanding the actual deployment realities of networking technologies is important. In fact, I have a few writing projects planned that will return to this sort of work in the near future. I still read the Day One series, and watch Ivan’s excellent webcasts, and even read the various OpenStack guides.

On the other hand, what I learned by writing Optimal Routing Design, and by interacting with the coding side of the engineering community, and with business folks who are struggling to understand the impact of all this technology on their bottom line, is that there is more than one realm of knowledge in network engineering. On the one end we could place the configuration of any specific piece of equipment, protocol, etc. On the other, we could place graph theory in all it’s resplendent glory (I think that I shall never see, A graph more lovely than a tree). Network engineers tend to find one spot, or “comfort zone,” on this range of knowledge, and stick with it — almost to the point of deriding anything beyond our little “comfort zone” as “useless,” or “not practical,” or…

But what I’ve discovered, over the years, is that if I know the principles, and learn how to build models and ways of thinking about them, I can apply them to a wide range of problems. In other words, to bring the example to a more finite example — I can learn how to drive a car, or I can learn how cars work in relation to their being driven. If I see these two as orthogonal sets of skills, then I will see one of the two realms of knowledge as being “not so useful.”

If I see them as complimentary sets of skills, however, then I can make great headway in learning how to take on new technologies and ideas, and to fit them into what problems really need to be solved, how engineers have attempted to solve those problems in the past, etc. Rather than just looking at how to deploy this protocol on that box, I could learn to be the driver who can drive every vehicle from a scooter to a tank (or a large truck, depending on your preference).

What I’ve learned is I need a frame of reference, rather than a configuration guide.

And that’s why my last book, and my current one, are more theoretical. In fact, my current book, Navigating Network Complexity, is even more theoretical in nature. Yes, I’m trying to illustrate the concepts with design and architecture realities, but I expect you’ll have already read Optimal Routing Design, and then The Art of Network Architecture, when you’re perusing it’s pages. In other words, I’m not trying to put the full scope of network engineering thought into one book, but across a lot of books over a number of years.

We need to stop thinking of engineering as a set of disconnected bits and pieces stretching out into many different little compartments. We need to learn to think of theory and practice as two connected “things” along a single continuum of engineering space. When a sentence begins with “in theory…” it doesn’t mean the rest of the thought is going to be impractical mumbo jumbo, any more than a sentence beginning with “you configure this…”

You can’t really think outside the box in the real world. You can, however, get a bigger box in which to do your thinking.

BTW, if you’re reading this on the day of publication, I’m at Interop this week. Feel free to look me up, as I’m likely to be wandering the halls just talking to anyone I come across. 🙂