How I Made Peace With Dashboards

I am a recovering programmer. By that, I mean that I used to love to code all the things. Why acquire a tool when you can just build what you need? Or so my thinking went back when I had less of a sense of the value of my own time. “Acquire” applied to buying something or bringing in an open-source solution. If you just built it, you didn’t need to worry about EULAs or copylefts or interoperability or any of the other messy things you don’t have to deal with when you build 100% of what you need from the ground up.

Dashboards were at the top of my list. Why acquire a thing to analyze and display data when you can build exactly the analysis and display you need and not deal with a bunch of stuff you don’t?

As the saying goes, youth is wasted on the young.

As not much time passed, I realized my approach meant that I was writing a lot of the same scaffolding and housekeeping code over and over, with not much variation. No one likes to do that so I quickly learned to make the common parts reusable. After a while, I realized that left me with a bunch of mundane components that I still needed to maintain when I really wanted to work on solving new problems. Suddenly, “acquiring” looked pretty good.

Eventually, dashboards and business intelligence platforms fell under the umbrella of things to be acquired rather than built. The primary reason for this is that they most often serve an audience other than their developers. No matter how well that audience articulates their needs for a dashboard - and no matter how well the developer meets those needs - that audience will invariably need a “tweak.” With a bespoke dashboard built from scratch, such a “tweak” can chew up a couple of sprints which, in turn, sideline valuable development resources.

Technology moves fast and I am no longer the programmer I once was. As a leader, I have come to realize that is true for everyone. Every developer has a window in their career during which - to use a baseball analogy - all the pitches slow down and the ball looks a lot bigger. Swing after swing puts you on base or goes over the wall.

As a technology leader, you best serve the careers of your team and the needs of your organization and users by placing your team in a position to do the highest-value work possible during the period of time in which your careers intersect. That means reducing the amount of work they do on commoditized tasks as much as is possible. Dashboards and BI long ago fell into this category.

Dashboards are an imperfect communication medium. When they are poorly designed, they can lack clarity and context, being overstuffed with data or cluttered with too many charts and visual elements. They can fall victim to data quality issues and, because of their highly visual nature, run the risk of accentuating those quality issues or, worse, accelerating decisions made based on poor data. They can quickly become misaligned to user needs - see the “tweak” discussion above.

Any of these situations can trigger a couple of sprints in order to resolve them, sidelining developers on non-strategic work. Business intelligence platforms can mitigate some of this by making it possible for users to self-serve their visualizations in a sandbox that is safely abstracted from live, production data. This can allow technical resources to focus on pushing quality data to users, who can then build their own dashboards.

BI platforms essentially move risk, rather than fully eliminate it. Users don’t always understand data analytics and can build spurious visualizations even with high-quality data. But the BI platform can enable dialog that can allow users to get better and join in a collaborative relationship. Over time, dashboards get better and developers can focus on high-value tasks.

Most BI platforms offer limited options for visualization. Those of us in the geospatial sector will know full well the challenges of trying to deliver quality geographic visualizations through BI platforms. There will still be the occasional need for developers to build something bespoke, but effective use of a BI platform should reduce those instances, and allow users to iteratively build dashboards that are relevant to their needs and those of the organization.

I no longer feel the need to build everything. I use Wordpress, I like autocomplete, I like drag-and-drop UI builders. I will happily accept as much help as my tooling wants to give me. I see that as a sign of maturity. Dashboards and BI, for as much as the developer in me still loves to hate them, are also mature and belong in the portfolio of any organization that is serious about getting the most innovation it can out of its developers.

I can’t believe I said that out loud.

Thank you for reading.