Premature optimisation

Premature optimization is the root of all evil.” (1)
Donald Knuth
.

I find it interesting that “automation” has become such a common buzz-word in the vernacular of virtualised networking… and OSS for that matter. It seems that it has become one of the primary expectations from any network management project.

I can understand that automation should be an objective because of the potential efficiency gains that it brings about, in some cases justifying the very business case upon which the project was built. But I also see automation as being a longer-term deliverable in many cases.

I always recommend performing tasks manually at first with the procedures and systems your project has built. This allows operations teams to learn, observe and refine to the unique conditions of your OSS ecosystem (and beyond). Once the ops team is comfortable that the process has been bedded in, they know exactly how it works and they know they’re capturing any exceptions that are being thrown, then you’re ready to start building OSS automations.

Naturally, some domain managers will have built-in automations, which is based on the prior learning (the learn, observe and refine phases) of the organisation that has architected the domain manager. Even still, there will be unique conditions relating to your ecosystem that may not be catered for in their pre-built domain automations. I’d recommend observing their automations closely, particularly to ensure all exceptions are captured somewhere. Perhaps even construct some test cases to try to force exceptions and watch what occurs.

(1) Footnote:
The broader context of Donald Knuth’s quote above is as follows:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

This takes Pareto’s 80/20 rule further, to Knuth’s equally arbitrary 97/3 ratio. His sentiments are reflective of the OSS industry too, as described in this earlier blog named, “Slaying performance dragons.” On high-volume transaction systems like OSS, the 3% can make a staggering difference to the user experience, but project teams should not optimise to the detriment of the project’s other time / cost / functionality / deliverable / benefit objectives.

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

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.