Another reason why I hate building dashboards — it's an invisible job. Careerwise a dashboard is a black hole. It consumes loads of you time and gives nothing back, just grows to be an even bigger problem.

Problem 2: How hard it can be

You know that feeling, when you decide to support your findings with a chart and get from a manager "Oh, that's a nice chart, we should have it in our dashboard". Instant regret.

Am I being a diva? I mean, how hard it can be, you basically have the whole thing done, all you need is just to press a magical button "execute daily".

Not quite. And there are three reasons why it's not that simple.

1/

Unlike most of developers, analysts write a lot of disposable single-use code. It is not meant to be rerun unsupervised, moreover quite often it's not even possible to rerun it in one piece. We take shortcuts, we filter out data using very case-specific signs, we even copypaste when no one's around. And it's not us being bad coders, it's the specifics of this type of job.

To make that frivolous code run day by day, with seamless connection through dates, with general indicators for dividing and filtering data (that stay somewhat sustainable through project development) — that's a whole another task.

2/

Data delivery is not that reliable. Let's face it: data for product analytics is not vital for service being up and running, so it gets fucked up relatively often. Delays, downtimes, glitches, and "Ooopsy, we forgot to add that logging you asked for in a new release" is a daily struggle.

So, each chart needs a life-support system: workarounds for all kinds of glitches and delays, automated recalculations backwards and informative alerts for failures.

3/

If you have an interactive dashboard, every new chart needs to be prepared the same way. Sometimes it's a few extra lines of code attaching the same hierarchy for a charted feature. Sometimes it's a logical puzzle of trying to squeeze new data into the old frame. And a cherry on top: every new chart slows down rendering time for the whole dashboard. Sometimes — to the level of the dashboard becoming unusable.

So, adjusting dashboard to include new charts is not just squeezing in a new widget. It takes time and taste, it requires communicating with users of that dashboard, it implies rebuilding it and even making major dashboard redesigns when needed.

How to deal

The problem is not the workload itself. The problem is a significant underestimation of the resource it takes to run a dashboard.

So the first thing I highly recommend here is learning how to communicate clearly. As simple as it seems, people don't do it that often. You can say something like "I can add that chart to a dashboard. It would take me 2 days to make it ready for an unsupervised runs, and one more day to configure all the adjacent parts. Also I assume it would take another hour per month for maintenance"

And that it's your manager's call to decide, if that chart is worth it.

Second thing is reducing the amount of this invisible job, by building your code bound and self-sustainable. My must-have tricks are check-and-sleep cycles for all the data sources and recalculation backwards for all missing datapoints. Also I always use common precalculated and groomed data instead of raw one. It allows to solve every new emerging problem once and for all.

Talk to me

Do dashboards eat up your time? What are your pro tips on how to avoid it? Let's discuss it and next time we'll talk about the most irritating issue that comes along with dashboards.