[cratermoon]

> 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?

[devchix]

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.

[arrrg]

Yeah, but why?

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

[cratermoon]

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.

[devchix]

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?