Hacker News Reader

Comment by carlmr | Hacker News Reader

>For example, an analytics dashboard built with a no-code analytics tool like Looker is likely to have more qualified people to fix it than one built with a patchwork of custom scripts and APIs. Nobody should have to pull data scientists or product developers away from their work to fix a bar chart.

I don't have experience with Looker, but the unseen complexity of no-code tools often leads to very complex systems with interactions that are hard to understand. A dashboard may not have that many interactions with other tools, but the black box nature of these kinds of tools usually leads to significant downtimes when there's a small detail not working as expected, or where you need a small customization that wasn't foreseen by the no-code API creators.

View on HN

As somebody who built a lot of Looker, it is not no-code for this very reason. It's why your Looker data model is stored in hand-editable code and under version control!

Looker isn't no-code. A lot of people consider Looker a slightly more robust Tableau, but the visualization aspect is almost inconsequential. It's the data modeling part, the "this is exactly what structure my data takes and we define that in code", that matters. Otherwise what you get is "Here's my Tableau workbook with an unholy pile of hand-written untested SQL as custom data sources"

Incidentally I'm all ears if there's a good open-source LookML style project out there.

That's true for drag&drop tools that provide a user interface as an alternative but Looker or similar tools introduce their own language that limits your capability by sandboxing the environment but still lets you programmatically define your models. See LookML for Looker (https://docs.looker.com/data-modeling/learning-lookml/what-i...) or Jsonnet for Rakam. (https://docs.rakam.io/docs/compose)

P.S: I'm affiliated with the company Rakam.

I think that’s missing the point he was making. No matter what front-end representation of a system you get, the implementation backing a no-code system will have edge cases around interactions both internally and with third-party systems. The fact that you’re hiding a system behind a veneer of “no code” doesn’t hide the fact that code is behind the actions that are taking place, it just means you can’t introspect it (even if this “no code” is in fact code).

I think a better point would be to make that that’s not a bad thing, sometimes abstractions provided in “no code” systems can greatly simplify a solution. But even the most well-designed solution will fail to some essential complexity of the root-problem the original authors didn’t understand. Without debugging tools (or privileged access to the backend of the implementing system) it’s difficult or impossible to understand what went wrong.

Spot on. Looker is a great tool, but it has its own language LookerMl and a set of abstractions. From my limited experience it‘s not easy to pick up. It‘s likely that an analyst is already familiar with it. But like with any BI if there is a problem that can‘t be solved with an existing abstractions and tools, you either go back to writing the pipeline step to solve or you come with a very ugly solution.

I think the point, actually we don't have to think, it was stated explicitly, is that if Looker breaks, you can easily switch to an alternative.

This was presented as the rationale quite plainly, so I don't understand why people are missing it.

Reply on news.ycombinator.com