As someone who frequently has to write custom SQL queries for business people I feel this. So far I haven't found any better solution than simply giving them the queries, which they save for...
As someone who frequently has to write custom SQL queries for business people I feel this. So far I haven't found any better solution than simply giving them the queries, which they save for themselves so they can run them again on their own. The fun part is when they try and modify the queries and get wrong results due to lack of knowledge on the overall database scheme design. But in the grand scheme of things, plain SQL and a good QA process for mission critical analytics can go a long way in practice.
The problem at my company was exactly that, everyone ran their own queries so several teams delivered different metrics for things that should at least align. Sometimes the same team delivered...
The problem at my company was exactly that, everyone ran their own queries so several teams delivered different metrics for things that should at least align. Sometimes the same team delivered different results for the same question.
My Data Analytics team had the job of blocking reports from other teams, standardize every metric and funnel everything through us. If there’s a new metric, it has to come from our Looker dashboards (this damn platform is going to be the end of me)
This created a lot of stress (and still does), many people didn’t like this move. They were used to just grab a query, adapt it, and report it. Yes, it allows for more autonomy and quicker deliveries, but at the cost of accuracy and coherence.
I relate to what the article is saying, but I also know the other side of the coin. I don’t really know what’s the sweet spot between both sides
Thankfully we have a general understanding that their access to the read only database is use at own risk. So important business metrics that will be used for critical decision making will usually...
Thankfully we have a general understanding that their access to the read only database is use at own risk. So important business metrics that will be used for critical decision making will usually be run by some tech person first. But not sure that ad hoc approach scale well to larger organizations.
I’m wondering if something spiritually similar to sending a pull request would work, where they can write a SQL query and try it out on old data, but they have to send it in for review and then...
I’m wondering if something spiritually similar to sending a pull request would work, where they can write a SQL query and try it out on old data, but they have to send it in for review and then you publish it. (After fixing it, maybe.)
Random aside, I use Looker for my reporting. I haven't had any issues, but then I just use it to look at data. I'm curious what you don't like about Looker?
Random aside, I use Looker for my reporting. I haven't had any issues, but then I just use it to look at data. I'm curious what you don't like about Looker?
I hate it but it’s not its fault, it’s just not the right tool for us but company demands that we use it. So we’re stuck with all the negatives and can’t enjoy none of the positives Some teams...
I hate it but it’s not its fault, it’s just not the right tool for us but company demands that we use it. So we’re stuck with all the negatives and can’t enjoy none of the positives
Some teams that we have to work with demand very specific logics in their metrics, so we end up having to depend on derived tables more often than not. So almost every time we have to create a new dashboard, we can’t use previously created views.
I already tried to explain to business that Looker Studio (previously called Data Studio) exists and that it’s a more versatile tool, and would suit these teams a lot better and would allow us to create dashboards faster. But for whatever reason they insist on looker.
Fun historical fact: SQL (whoops) was intended to be used by the business people to attain data, saving the programmers from needing to do so. It was one of the original "low code" solutions....
Fun historical fact: SQL stands for Simple Query Langauge (whoops) was intended to be used by the business people to attain data, saving the programmers from needing to do so. It was one of the original "low code" solutions.
Instead, tech ignorance was permitted to permeate. And the programmers have tried (via vendor solutions or homegrown) again and again to offload any degree of this data reporting to the people requesting the data, with little success.
Its for this reason I don't think low-code/no-code solutions are really viable across the board. They don't solve the social acceptability of tech ignorance.
Funny you say this, because I start a job on Monday where my responsibility will be to, essentially, clean up the mess and set new rules for data and dashboard management. Because exactly what you...
Funny you say this, because I start a job on Monday where my responsibility will be to, essentially, clean up the mess and set new rules for data and dashboard management. Because exactly what you described happened - developers keep being asked to manage the query side and setup dashboards, but the devs aren't experts in [my field], but are.. you know.. developers... But the experts don't know how to query etc., so what we get a bunch of dashboards the experts can sortof use but not very efficiently, and the developers are being pushed to report on more and more metrics that they don't understand the interactions between because theyre developers and not freaking field experts!!
So now I get to make my living as an expert in the field, who taught themselves the knowledge necessary to setup the data warehousing, dashboards, reporting tools, governance, etc.
It's a neat niche that I hope to really make my mark in!
It is indeed a powerful thing to have both the deep subject matter knowledge and the ability to use the tools to leverage it best. As a DBA, my favorite staffers to work with were the ones that...
It is indeed a powerful thing to have both the deep subject matter knowledge and the ability to use the tools to leverage it best.
As a DBA, my favorite staffers to work with were the ones that basically just needed access to Cognos and would only ever ask for additional permissions as needed.
We've actually had decent luck with Tableau in terms of giving non-technical people access to queryable data. You do have to set up the base reports but then they can apply filters as they please....
We've actually had decent luck with Tableau in terms of giving non-technical people access to queryable data. You do have to set up the base reports but then they can apply filters as they please. And it's also easy enough that you can have a mildly-proficient technical person build dashboards instead of a developer creating homegrown tools..
I work in the no-code/low-code space (Pega, ServiceNow BPMs) as a developer which is basically the 'use case' for this - making reports (and 'everything' else!) accessible and maintainable by...
I work in the no-code/low-code space (Pega, ServiceNow BPMs) as a developer which is basically the 'use case' for this - making reports (and 'everything' else!) accessible and maintainable by people with limited technical knowledge. happened to work on tableau integration recently. "citizen developers"! what ends up happening is only the actual application devs configure the reports and dashboards for everyone else and lock everything down because despite how 'easy' it is, users will always mess up. Although I suppose what it does is still better than giving them raw SQL code in that they can filter reports, create graphs etc. super easily.
As someone who frequently has to write custom SQL queries for business people I feel this. So far I haven't found any better solution than simply giving them the queries, which they save for themselves so they can run them again on their own. The fun part is when they try and modify the queries and get wrong results due to lack of knowledge on the overall database scheme design. But in the grand scheme of things, plain SQL and a good QA process for mission critical analytics can go a long way in practice.
The problem at my company was exactly that, everyone ran their own queries so several teams delivered different metrics for things that should at least align. Sometimes the same team delivered different results for the same question.
My Data Analytics team had the job of blocking reports from other teams, standardize every metric and funnel everything through us. If there’s a new metric, it has to come from our Looker dashboards (this damn platform is going to be the end of me)
This created a lot of stress (and still does), many people didn’t like this move. They were used to just grab a query, adapt it, and report it. Yes, it allows for more autonomy and quicker deliveries, but at the cost of accuracy and coherence.
I relate to what the article is saying, but I also know the other side of the coin. I don’t really know what’s the sweet spot between both sides
Thankfully we have a general understanding that their access to the read only database is use at own risk. So important business metrics that will be used for critical decision making will usually be run by some tech person first. But not sure that ad hoc approach scale well to larger organizations.
I’m wondering if something spiritually similar to sending a pull request would work, where they can write a SQL query and try it out on old data, but they have to send it in for review and then you publish it. (After fixing it, maybe.)
Random aside, I use Looker for my reporting. I haven't had any issues, but then I just use it to look at data. I'm curious what you don't like about Looker?
I hate it but it’s not its fault, it’s just not the right tool for us but company demands that we use it. So we’re stuck with all the negatives and can’t enjoy none of the positives
Some teams that we have to work with demand very specific logics in their metrics, so we end up having to depend on derived tables more often than not. So almost every time we have to create a new dashboard, we can’t use previously created views.
I already tried to explain to business that Looker Studio (previously called Data Studio) exists and that it’s a more versatile tool, and would suit these teams a lot better and would allow us to create dashboards faster. But for whatever reason they insist on looker.
Ah, okay. Makes sense, appreciate the extra context!
Fun historical fact: SQL
stands for Simple Query Langauge(whoops) was intended to be used by the business people to attain data, saving the programmers from needing to do so. It was one of the original "low code" solutions.Instead, tech ignorance was permitted to permeate. And the programmers have tried (via vendor solutions or homegrown) again and again to offload any degree of this data reporting to the people requesting the data, with little success.
Its for this reason I don't think low-code/no-code solutions are really viable across the board. They don't solve the social acceptability of tech ignorance.
The S in SQL is Structured, not Simple.
Thats what I get for fully trusting pre-coffee brain.
Funny you say this, because I start a job on Monday where my responsibility will be to, essentially, clean up the mess and set new rules for data and dashboard management. Because exactly what you described happened - developers keep being asked to manage the query side and setup dashboards, but the devs aren't experts in [my field], but are.. you know.. developers... But the experts don't know how to query etc., so what we get a bunch of dashboards the experts can sortof use but not very efficiently, and the developers are being pushed to report on more and more metrics that they don't understand the interactions between because theyre developers and not freaking field experts!!
So now I get to make my living as an expert in the field, who taught themselves the knowledge necessary to setup the data warehousing, dashboards, reporting tools, governance, etc.
It's a neat niche that I hope to really make my mark in!
It is indeed a powerful thing to have both the deep subject matter knowledge and the ability to use the tools to leverage it best.
As a DBA, my favorite staffers to work with were the ones that basically just needed access to Cognos and would only ever ask for additional permissions as needed.
We've actually had decent luck with Tableau in terms of giving non-technical people access to queryable data. You do have to set up the base reports but then they can apply filters as they please. And it's also easy enough that you can have a mildly-proficient technical person build dashboards instead of a developer creating homegrown tools..
I work in the no-code/low-code space (Pega, ServiceNow BPMs) as a developer which is basically the 'use case' for this - making reports (and 'everything' else!) accessible and maintainable by people with limited technical knowledge. happened to work on tableau integration recently. "citizen developers"! what ends up happening is only the actual application devs configure the reports and dashboards for everyone else and lock everything down because despite how 'easy' it is, users will always mess up. Although I suppose what it does is still better than giving them raw SQL code in that they can filter reports, create graphs etc. super easily.