Sound and Fury!

The phrase “full of sound sound and fury, signifying nothing” is part of one of the most famous soliloquies in the English language. It appears in William Shakespeare’s Macbeth (Act 5, Scene 5, lines 17-28):

“She should have died hereafter;

There would have been a time for such a word.

— To-morrow, and to-morrow, and to-morrow,

Creeps in this petty pace from day to day,

To the last syllable of recorded time;

And all our yesterdays have lighted fools

The way to dusty death.

Out, out, brief candle!

Life is but a walking shadow, a poor player

That struts and frets his hour upon the stage

And then is heard no more. It is a tale

Told by an idiot, full of sound and fury

Signifying nothing.”

Easy to picture Patrick Stewart playing the Scottish king on a stage with a sword at his hip, but I was surprised and pleased to find a clip of him giving this soliloquy in a modernized television film, holding an assault rifle (https://www.youtube.com/watch?v=qNDWBWFrpjM). I was not previously aware of this 2010 production of Macbeth (https://en.wikipedia.org/wiki/Macbeth_%282010_film%29), but will definitely add it to my list.

(I also found a very interesting clip of an interview with Patrick Stewart on how to deliver this soliloquy, with some advice from Ian McKellan https://www.youtube.com/watch?v=9YGf_goOoDk)

That phrase, though, makes me think about many presentations I have seen over the years. There are endless ways to make a presentation, and endless techniques to make an impact when presenting, but if your goal is to provide clear, useful, actionable information, there are some basics you really need to be aware of.

As far back as I can remember (back to at least the 1970s), my father used to say about public speaking: “be brief, be bright, be gone”. I had a quick look to see if I could find a source for it, and was rather surprised to see it attributed to the author of a book intended for pharmaceutical sales representatives... written in 2001. I dug a bit more, but mostly found attributions of a variation (“Be sincere; be brief; be seated.”) attributed to Franklin D Roosevelt. (https://www.brainyquote.com/quotes/franklin_d_roosevelt_164074). I decided not to go down this particular rabbit-hole.

At any rate, the factor that is probably the most important in getting a message across is clarity. I believe I have previously mentioned Isaac Asimov (https://en.wikipedia.org/wiki/Isaac_Asimov) and his ability to clearly explain the core concepts of even the most complex topics. Well, that’s what I am talking about. And, since we all know that a picture is worth a thousand words, we should all add lots of pictures and graphs to our presentations, right?

Sadly, that is exactly the wrong advice, and I have seen many presentations filled with graphs that don’t give any useful information, don’t explain anything, and don’t even establish context – “full of sound and fury, signifying nothing”. I found one post that describes “The 27 Worst Charts of All Time” (https://www.businessinsider.com/the-27-worst-charts-of-all-time-2013-6), and wow. Just, wow. Have a look if you want a laugh.

I don’t want to bash on horrifically bad graphs and charts (though that might be fun), but want to highlight the importance of knowing what you want to say. Even if your graphs are clean, clear, well-labelled, and accurate, that doesn’t help much if you are measuring something that doesn’t really matter.

I seem to keep going back to Alice’s bookstore (https://www.til-technology.com/post/_risk), but it just keeps seeming appropriate. Let’s say that Bob is creating reports about the security vulnerabilities and patching that the team is applying.

One of the charts is a beautiful and clear chart describing the specific threat actors known to be exploiting the vulnerabilities identified in their environment. Bob has put a lot of work into ensuring that the data is as accurate as he can make it, and as clear as possible.

But how useful is it? How much data is actually available? How reliable is it? How quickly does it change? The answer, of course, is that it is extremely difficult to gather and manage this sort of data, the data is often fragmentary or speculative, and the process inevitably includes a number of judgment calls and estimates.

More importantly, though, what decisions might be made based on this data in their environment? Will Bob recommend that Alice make a different decision because one of the vulnerabilities is known to have been exploited by the Malice threat actor, as opposed to the Malbot threat actor?(Keep in mind that we’re talking about a bookstore that focuses on cat videos here...)

After some thought, Bob realizes that it doesn’t really matter who is attacking them – it’s safe to assume that someone is very likely to attack them eventually if they don’t resolve the vulnerability, since many threat actors simply search the internet for potentially vulnerable systems and attack them. After a sigh (it really is a very nice chart), Bob sets it aside in favour of something more practical.

Bob already has charts clearly describing vulnerabilities by urgency, age, and Service Level Agreement (SLA), with trending values, to ensure that numbers are moving in the “right” direction. What about a chart describing the usual time between the availability of a patch and reports of the vulnerability being exploited? That might help to confirm whether the SLA values are calibrated correctly – the obvious best-case would be to resolve all vulnerabilities BEFORE there is confirmation that they are being exploited “in the wild”, and we would obviously want the lag to be as short as possible, to minimize risk to the organization.

Sounds interesting, but the real question is why we want to devote effort to gathering and presenting this information? Assume that we can build this report and make it clear and accurate. What decisions could we make as a result? Well, if we have a better understanding of the likelihood of a vulnerability being exploited within a given timeframe, we could adjust our SLA values, decide to expand/improve automation of patching, or adjust our processes around requesting approval to defer/delay updates. Assuming that the “basic” processes are in place and working reasonably well, there might be significant value in this new report, so Bob decides to include it.

Which brings us back to appearance and design.

That’s actually a pretty big field and a lot of research has been conducted around techniques for building effective graphs and charts. There is a well-established discipline to this, and a number of “rules” and guidelines, but it’s often most effective to simply break down “bad” charts, describe why they’re bad, explain the “rules”, and then use them to build a better chart.

There is an interesting site called “Junk Charts” (https://junkcharts.typepad.com/junk_charts/), which does exactly this. In one post, https://junkcharts.typepad.com/junk_charts/2021/03/re-engineering-onelesspie-.html), there is a truly hideous chart:

This chart is reviewed, it’s flaws examined, and a vastly superior chart is proposed. I won’t spoil it for you – go check out the site.

Getting back to Bob, a very good place to start is to build some very simple graphs and charts describing key data points, then work with Alice to see what questions and other data points come up. Generating that dialogue is an excellent way to not only build buy-in, but also build the most useful set of reports for a given organization.

Cheers!