Complicated isn’t clever

Complicated isn’t clever. It just looks clever to stupid people.”
Dave Trott

Regular readers will have noticed how often l refer to OSS being complicated, too complicated. So if Dave Trott is right, and I do think he might be onto something, then OSS isn’t as clever as l might try to persuade you.

I recall an NMS solution that had enormous power (in theory) and had been created by some seriously bright engineers / analysts / developers. The only problem was that it was pretty close to being unusable.

Part of the problem was that it was managing a network that was convoluted but it also seemed to be designed with a bunch of even more convoluted edge cases in mind rather than streamlining on the common use cases. Was this a case of a solution looking clever to these very clever implementers or were they not so clever for developing a barely useable tool?

It’s an important line of questioning to keep asking ourself in this industry. For example, l recently created an OSS mapping spreadsheet that made perfect sense to me and suited a variety of my needs well. However, it was also needed to articulate a message to a large group of customer representatives. Unfortunately it failed. It was too complicated for them to quickly grasp so l had to hack it back to a much simpler message.

We probably all over-complicate things at times don’t we? I know l can fall into this trap unfortunately. We probably also need to be more forthright in asking others to simplify if we’re to make OSS cleverer too.

[And that goes for you if I’m ever getting too complicated here on PAOSS] Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “Complicated isn’t clever

  1. OSS vendors have to add new products and clever new features, and often fail to circle back and improve or simplify core capabilities.

    “Inventory? Done that. Let’s go and create a highly sophisticated process and service/resource model for encoding service provisioning next….”

    Or you could make navigating and working with the inventory simpler and more consistent instead.

    Edge cases are the norm in network engineering. So I sayz, let’s make the core tools simpler to use rather than trying to automate the heck out of something that can’t be defined consistently in the first place.

    For instance.

    Build complicated automated network routing algorithms that need to model cost and technical constraints? Or build a simple way for a user to navigate across hops in the network while assigning resources? Ok, the latter is slower to run per route. But I’d argue that it’s much faster to deploy, therefore faster to see benefits, and being a ‘guided’ manual task it can handle the inevitable edge cases the engineer will throw at it.

    For instance.

    Create a network optimization algorithm that analyses and reroutes service paths, for a theoretical optimum design that would take years to roll-out in practice? Or provide data analytics of routes to highlight questionable designs to engineers to identify quick win reroutes?

    But, no one spent $5m on OSS to make their engineers’ jobs easier. If you can’t sell it as automation, you can’t justify the RoI.

  2. Hi James,
    You make an interesting set of arguments (as usual).
    Your last sentence is the most interesting of all. Automation is indeed the big cost-out selling point that seems to sell OSS at the moment. The big question (in my mind) is whether anybody actually measures the RETURN on investment (ie during / after the project), or do they just estimate the ROI up-front and allocate the $5m on that?! 🙂

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.