Hacker News new | ask | show | jobs
by clipradiowallet 1763 days ago
From TFA... >every dashboard is a sunk cost

>every dashboard is an answer to some long-forgotten question

>every dashboard is an invitation to pattern-match the past

>instead of interrogate the present

>every dashboard gives the illusion of correlation

>every dashboard dampens your thinking

I disagree with this on all counts. A dashboard is a way to view multiple disparate metrics in a single place. Whether they are correlated isn't important(but it is helpful).

And the author doesn't stop there...

> They tend to have percentiles like 95th, 99th, 99.9th, 99.99th, etc. Which can cover over a multitude of sins. You really want a tool that allows you to see MAX and MIN, and heatmap distributions.

They "tend to"? "You really want"? The author is confusing their own failures/gripes around the concept of dashboards with the world's experience with dashboards. By the end of the article, I was shocked they weren't selling something.

5 comments

> A dashboard is a way to view multiple disparate metrics in a single place.

This is technically correct but doesn't approach anywhere near the criticisms the article has.

The deeper questions are: how did those metrics come to be collected, and why? What happened that resulted in those particular metrics being aggregated and displayed they way they are? What questions were being asked at the time the dashboards were created?

> a way to view multiple disparate metrics

So what? Why view them? Pretty graphs? A red/yellow/green? But to what end? This is why the statement is technically correct, but sheds no light at all on the reasons why a developer or customer support troubleshooter would care to look at the disparate metrics gathered in a dashboard.

Dashboards are created in response to certain problems and events. Those problems and events may or may not be relevant some time down the road. What happens when someone in the present with a certain set of questions or problems looks at the dashboard full of metrics capturing past questions and forgets that those questions are not today's questions?

That's why good dashboards come with Title, subtitle, legend, the X and Y axis, and units. Count of packets denied from source IP, source port, last 4 hours. Average number of requests forwarded to proxy farm, distributed by server, last 7 days vs. same time last month. Who called 2049, last 24 hours.
Yeah, but why?

You are talking tactics, not strategy. What are the underlying goals?

Great, so I know exactly what I'm looking at. But it's not showing me anything I need to know to figure out why half the company is yelling at the team in Slack that something is terribly broken.
You are here, lat=x, long=y, bearing N 45 E at 5km/h, the air temp is -12C, it is 45min to sunset. You don't know where you should be. You are lost. Who's fault is it? Yours, or the dash?
I mean, she is selling something. She is the founder (former CEO) of Honeycomb which is all about doing ad hoc queries rather than setting up dashboards.
Get 'em
People frequently get dashboards wrong, it is true. I like them for genuinely important things - I want klaxxons when there is a customer-facing issue, for instance. These should be simple and hard to confuse.

I also like them for whatever KPIs are considered important this week. A slightly sneaky reason is that time has to be budgeted to modify the dashboard and they are very visible, so dashboards also advertise when the goalposts move. (My current employer is actually not bad about this. This lesson came from $job-1.)

Hear hear.

At CoreOS I set up a number of dashboards specifically to socialize the normative behavior of our systems. Think of it as the difference between the person who just drives their car versus the person who knows what feels and sounds "normal".

The latter can tell when they need an oil change because of different vibrations in the engine and how the car sounds pulling up to a stop light (because of the engine sounds being reflected back into the window by parked cars).

Big surprise, it had the desired effect.

I'm especially with you on the notion of disparate metrics. While correlation is not causation, it's still a useful diagnostic tool.

Let's say someone in marketing walks a dashboard and and sees the following:

1) a new version has been pushed 2) customer tickets are up 20% over the number they're used to seeing

Does that mean that the new version caused the tickets? No. Will that allow them to ask? Absolutely. Will that urge behavior to reach out to support and release management to see if there's an interesting story to share internally (or with the world)? Hopefully.

You hit the nail on the head by calling out the absolutist / "I'm the authority on this matter" / "there is a single correct perspective" tone.

Your lack of shock at the author selling something can be remedied. They have a dog in this fight: https://www.honeycomb.io/teammember/charity-majors/

+1 on this. You really need something to tell you what "normal" looks like. Things like what the busy times are each day or what the normal number of requests/errors are.

If you have no feel for what normal looks like on you system then it'll take longer to notice problems and longer to fix them.

I agree with both viewpoints in certain ways, a lot of times visualization surfaces issues that would otherwise go unnoticed but I think the important point is that being able to drill down is important for context.