The Danger of "Over-Engineering" : Ethan Banks

The Danger of "Over-Engineering"

by Ethan Banks

Over many years of singing sacred music in church choirs, I've performed in dozens of concerts and sung hundreds of songs. Some of that music was easy to perform: the sheet music was easy to follow, and the arrangement predictable. Other pieces may have been not only easy, but also unexpected: a familiar piece such as "Amazing Grace", but arranged in a such way to surprise the listener and hold their attention. Yet other pieces were genuinely challenging to learn and perform because the music's rhythms and melodic intervals required great attention, or the choir members had to sing against each other in competing melodic lines, such as in the "Hallelujah Chorus" from Handel's Messiah.

Singers tend to be opinionated about the music they are performing. With 50 or 100 members in a choir, it's unlikely that everyone will like every piece a director picks out. Perhaps an individual finds the music too boring, or conversely, beyond their level of talent. Some music rubs a singer the wrong way because their part doesn't "feel right". A singer might feel disconnected from the music, mechanically singing what is written, but not emotionally engaged. In my experience, there have been pieces where the music was so beautiful, it was a force of will to continue performing without being overcome. Other times, I've sighed in resignation as the director called for a certain piece that didn't inspire me.

When a choir performs the piece it has learned, the listening audience is experiencing various elements that work together to create the music: the melody around which the piece grows and thrives; the harmony of the voices that gives the music size and color; the rhythm that gives the work character and spirit; the director's interpretation guiding the singers through the rise and fall of each phrase, etc. One of the things I've learn about audiences is that they generally don't appreciate a piece of music because of how complex it is. A non-musical audience can't appreciate what might have been highly challenging for the choir to perform: they like or dislike a piece based on gut instinct. Sometimes a simple song is the one the audience enjoys the most.

Like a performing choir, you will often perform network engineering for an "audience" that doesn't function at your level of knowledge or skill. That audience might be a client for whom you're consulting, a technical manager, a project lead, or a peer who doesn't have the benefit of the study time that you've put in. You could be expertly singing a masterwork, and they won't be able to appreciate your offering for the thing of beauty that it is. Especially if you are preparing for a lab attempt, you are without a doubt learning techniques you did not know before. You're building your mental networking database to be bigger, probably much bigger, than it was. As different challenges come to your attention, you're finding that the solutions popping into your mind are different than they were before. "Hey, this is a good scenario for private VLANs." "You know, a static ARP list would solve that problem." "Ooooh, we could tunnel the OSPF to get around that." "Wow, what a great place to put one of those funky wildcard masks. I could get the ACL down to one line!"

Successfully applying what you're learning to the real world is fraught with challenges both social and technical. Here's some questions you might ask yourself as you consider your solutions:

Am I swatting a fly with a Buick? In other words, is your solution overkill for the problem at hand? The temptation will be to find a place in your production environment for some new skill you've obtained. For example, why use CBAC when a reflexive ACL will do? Why use a reflexive ACL when a traditional ACL will do? Why use an ACL at all if there's a separate firewall to do the job of packet filtering? Sometimes, you can legitimately answer the question "why". But if the answer is "because it's cool", then you need to step away from the keyboard and relax. There are those times you're singing the "Hallelujah Chorus", when a simple rendition of "Amazing Grace" would have done just fine.
If I get hit by a bus, will someone else be able to support this? There's really two issues implied by this question. The first is whether your solution is so complicated, that the only person who can readily fix it is you. Even when well-documented, highly complex solutions are often only able to be supported by the engineer that implemented them. Do you want to be that person? "Job security!" you might say. "I like to go on vacation without calls from work!" I say. The second issue is that of documentation and training. Are you willing to clearly document your solution? Are you willing to train your peers on your solution so that they, too, can support it? If you educate your audience, they are more likely to appreciate the song you're singing, and will maybe even learn to sing a few bars themselves. But if you aren't willing or able to train others on your team, perhaps it's best to choose a solution that the others are already familiar with.
How hard will it be to integrate this solution into the rest of the network? Networks are complicated things. The bigger they are, the more complicated they get. Therefore, you must consider any new technique in the context of the whole environment into which it will be placed. For example, enforcing MAC and IP pairings is a useful mitigation strategy for certain attacks, but how well does dynamic ARP inspection fit into a VLAN where there's no DHCP? Not terribly well. Therefore, you have to carefully weigh the advantages of the technology with the disadvantages of implementation. Would you convert that VLAN to DHCP? What kind of burden would that place on the sysadmins? Would you use static ARP filters? What kind of a burden would that place on the networking team? Sometimes a song is simply too difficult to learn for too little of a reward.
Is my ego getting in the way of common sense? From time to time, I run into engineers who come up with a solution as a way of showing off how smart they are. By recommending an over-the-top solution, they'll complicate the situation simply looking for accolades or awe from peers. If someone then asks why the obvious, equally effective solution wasn't employed, they'll defend their over-the-top solution to the death, hoping to get their way by being argumentative. Are you willing to back away from your solution when someone points out a simpler alternative? Are you willing to put down the score you fell in love with and sing something else when your audience goes, "That was really impressive, but I just didn't get it."?

Now that said, obviously you WILL use your newly found skills in the real world. That's one of the reasons a network engineer puts himself through the CCIE program, after all. There will be times when a complicated solution is absolutely the right one. You'll need to fight to make sure the right thing gets done; hopefully you fight with decorum and respect for your peers. Still, I think we've all been guilty of wanting to implement technology because it was cool, rather than because it was the right solution. We can't just sing for ourselves; we have to keep the audience in mind.

Ethan Banks is CCIE #20655 and works in the payment card industry.

Return to the top of 'The Danger of "Over-Engineering"'.
Send Feedback