The Design Mindset (3)

So you’ve spent time asking what, observing the network as a system, and considering what has actually been done in the past. And you’ve spent time asking why, trying to figure out the purpose (or lack of purpose) behind the configuration and design choices made in the past. You’ve followed the design mindset to this point, so now you can jump in and make like a wrecking ball (or a bull in a china shop), changing things so they’re better, and the new requirements you have can fit right in. Right?

Wrong.

As an example, I want to take you back to another part of a story I told here about my early days in the networking world. Before losing the war over Banyan Vines, I actually encountered an obstacle that should have been telling—but I was too much of a noob at the time to recognize it for the warning it really was. At the time, I had written a short paper comparing Vines to Netware; the paper was, perhaps, ten pages long, and I thought it did a pretty good job of comparing the two network operating systems. Heck, I’d even put together a page showing how Vines was a better fit with the (then mandated) OSI model (don’t ask how you mandate a model, it’s an even longer story).

I proudly ran off 20 or 30 copies of my paper, and passed them around to various folks. At a follow-up meeting, one of the more experienced folks said: “This is a great paper, if you’re just trying to justify your choice. If you’re actually trying to compare the two solutions, however, it’s not so great.” Ouch.

The problem is this is precisely what we do most of the time. Just like the “what versus why” in the first two steps, we tend to have solutions we’re comfortable with, we read about in that rag in the airport lounge, we heard about at some conference, or we really want to learn because it’s new and shiny (or it helps us study for a certification—I once worked on a network where the admins changed routing protocols because they wanted to study for the CCIE). We all worry about our skill set going stale, and we’ve all thought, at one time or another, that if we don’t deploy this new technology, we won’t have the skill set we need to find that next job. The fear of being left out drives far too many of our decisions.

How do you prevent yourself from going down one of these side alleys and making a bad decision? Even worse, how do you prevent incurring technical debt by reaching too far in the other direction—not being bold about getting rid of the old clutter that’s ossified into your network over the years and replacing it with newer ideas?

I’m going to suggest, as always, that we return to the complexity model, carefully asking about each side of the triangle to find the answers we need to decide what we should do. Specifically, ask—

• What state (the amount of state and the speed at which it changes) will this new technology add to the network overall, and to already existing systems in the network?
• What is being optimized for (here you need to go back to the business drivers), and why?
• What new interaction surfaces am I creating, or which interaction surfaces am I making deeper? Where am I increasing the dependencies between two existing systems, and where am I adding new ones? Make certain you look for leaky abstractions here, as all abstractions leak in some way.

Remembering this simple rule of thumb might help: If you’ve not found the tradeoffs, you’ve not looked hard enough.