"Hacky" Is Not A Dirty Word

It Depends

The word "hacky" has a bad reputation in data teams. Many developers and leaders hear the word "hacky" and this immediately brings negative connotations to their mind. They start thinking that hacky means bad practice, fragility, unprofessional standards and anti-patterns.

But....context matters. On one hand hacky can certainly be considered dangerous, corrosive and high-risk. But on the other it can be equated with creativity, playfulness, pragmatism.

"Hacky" per se is not the problem. It's using it in the wrong layer that is.

Two Kinds Of Hacky

I would argue hacky solutions can be split into two distinct camps.

Playful Hacky (The Good Kind)

The user interface exists to make the report look and feel good and intuitive for the end user. Using the art of the possible in terms of bookmarks, buttons, shapes, layering, conditional formatting. Producing reports that delight and make users exclaim "Wow! I didn't know you could do that in Power BI!".

Using buttons and bookmarks to create a pop up menu over the existing report is an example of this kind of hack.

The reporting layer is the terminus station for the journey that the raw data takes from source to analytical reporting. There are no further stages and therefore no knock-on effects on decisions made in this layer. Therefore the blast radius is small.

The advantages of this kind of hacky is that the risk is low if anything breaks. It will usually be confined to a report page or two. Which means it can quickly and easily be fixed or ripped out completely with little downtime.

This low risk for anything going wrong versus the upside of creating a unique, intuitive and cool looking report means this sort of hacky is encouraged. The upside ultimately outweighs the downside.

Structural Hacky (The Risky Kind)

This type of hack incorporates the following anti-patterns: inventing keys for relationships, building unnecessary bridge tables, creating bi-directional relationships, using implicit measures, copying DAX from AI.

Building a bridge table because a relationship "wouldn't work" is an example of structural hacky.

This is the dangerous kind as the effects aren't felt until further downstream. The numbers returned could be wrong but the root cause can be hard to get to. Not understanding why something is failing undermines trust in the data product as a whole.

Even more insiduously the numbers can be right until pressure is put on the system and then they fail. Again this breakage seems to "come from nowhere" and it can be hard to pinpoint the cause.

Because structural hacks occur earlier in the pipeline they can affect a number of different tables and so potentially have a high blast radius (the breadth of places a hack can create issues) downstream at the reporting layer.

Why Teams Confuse The Two

In most teams there is no distinction between these two different kinds of hack. All hacks are treated equally. This is due to a lack of understanding of the layering of data analytics and the interconnectedness of these layers.

As mentioned previously, the modelling layer exists before the report layer and therefore any changes made in the modelling layer will have a consequence in the report layer. Whether that consequence is immediately visible or not.

Coupled with this are the incentives in many organisations. These tend to favour velocity and getting tickets completed quickly. Consequently many junior devs don't see business intelligence as layered. They just want to work and create visuals in the report. So if a structural hack gets them past their issue, they will build one. Without necessarily understanding the consequences downstream.

How To Create A Hacky-Friendly Culture

Understanding the interaction between the different layers of BI is key here.

If analytics was house-building using hacky solutions in the modelling layer is tantamount to using hacks and shortcuts when building the house foundations. Whereas hacks in the reporting layer are equivalent to interior decorating. Exactly where creativity is encouraged and can flourish.

With this mental model in mind, I would encourage playfulness at the reporting layer. Allowing creativity and artistic flow here is when the best UI/UX features are born. And your reports will be elevated as a reward.

However, in the same way, shortcuts and hacks should not be in house foundations for fear of an instable structure, they should also not exist in the modelling and pipeline stage. Robustness is key here and any work done needs to be reviewed and approved to ensure rigour is followed. If anyone is using hacks here, they need to be removed and a different and better structured solution needs to be implemented.

The Bigger Cultural Point

So in summary, hacks are not really about what was done, but more about where it was done and the potential fallout further downstream.

A mature BI team knows when to embrace creative hacks and when to slow down and be rigourous. On the other hand teams that don't, pay the price long term with technical debt, eroded customer trust and firefighting.

Hacky is not a dirty word. In the right place and at the right time, hackiness is innovation. In the wrong place and at the wrong time, hackiness is debt.

The skill of BI is learning the difference.