Network Engineers don’t trust software…

A very clever colleague of mine, Keith, recently stated, “The failing of network engineers is that they don’t trust software (ie OSS, NMS, etc).”

Do you agree with Keith? Do you feel that most network engineers prefer to work from the command line rather than the GUI?

If so, why is that? Lack of confidence in tools based on past failures or functionality gaps? Speed / efficiency of task completion? Job security through having mastery of a more specialised interface? Other?

Is it true only within some domains (eg IP networks, network performance management, traffic engineering, etc) and not others? Enterprise networks or Service Provider networks?

If it is quite true, what do we have to do to regain their trust, and / or improve their experience of OSS tools?

I’d love to get your thoughts on this one.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

4 Responses

  1. In my experience by and large tools are trusted for monitoring however they are still viewed with suspicion for provisioning.

    The two main bugbears in our organisation are:
    1, Speed of the graphical tool – typically slower than CLI as it has to read in config, parse etc.
    2, The feeling of lack of control – i.e. the tools can be creating config the engineer may not be aware of. Coupled with stability this is a real issue if the gui breaks and the engineers have to re-work on the CLI.

  2. Easy to see when the NMS tools are behind a couple of minutes. Sometimes, even more. With smoothing, the NMS tools seem to give away the SLA window. This is especially critical when your in the middle of something in real time, trying to figure out whats wrong.

    Some NMS systems only handle traps they know about or the ones that are considered actionable. Inherently, they filter out data that could make or break the diagnosis.

    Some devices don’t respond to ICMP pings when things are under stress. (Go figure!) NMS wares vendors swear that this should never happen but their own myopia is at fault. If the only method of status is pings, you are kinda “rudimentary” or weak in your design and implementation.

    Amazing how much junk is out there. It is easy to mask bad behavior in your app. Like missing whole IP address ranges in discovery. (especially when NMap catches them! And the developers seem to only want to work on new features.

    A TON of marketing spinning and smoke ware. I see a bunch of spin jockeys call me up and try to tell me how their product is this or that and think that I’m wet behind the ears.

    With everything going towards continuous delivery, ironic how you don’t see any unit test apparatus in the products. Even the new stuff. Asking for a Unit test harness is like asking for an Audi engine in a Chevy truck.

    I also find it AMAZING how terms like Root Cause Analysis seemed to have been solved YEARS ago but somehow, it was only solved as a marketing check box.

  3. Hi Dougie

    Another great comment! Thanks!
    I tend to agree with all of your observations.
    The question becomes, “why haven’t they been implemented?”

    It’s not like any of them can’t be resolved technically. Is the challenge too difficult or the benefit too small? Or is it the current mode of features outweighing efficiency (ie focus on delivering more features rather than improving the efficiency of the vital ones)?

    I’m currently working with an organisation that “gets” your unit test harness. We’re currently developing and using it heavily for internal purposes because of the massive regression challenge of working for a customer that’s rapidly customising its best-of-breed OSS. But I can’t help but seeing it as a saleable feature for future customers.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.