![Code](/blog/code.webp) Let's write a post on something that I have been looking into lately - the way we handle Business Intelligence (BI). You know how we've all gotten used to those drag-and-drop BI tools? There is this new idea called "BI as code" that's starting to shake things up. I've been diving deep into both approaches, and I thought I'd share what I've discovered about how they stack up against each other. Let me break down the main differences I've found: ### How You Build Stuff - **The Coding Way**: Think of this like building with Lego Technic - you're writing code to create your data models and visualizations. It's pretty cool because you can use version control (like Git) to track everything you do. Tools like dbt and evidence.dev are leading the charge here. - **The Drag-and-Drop Way**: This is more like building with regular Legos - super intuitive and visual. You're using tools like Tableau, Qlik Sense, or Power BI where you can just click and drag things around. No coding required! ### Who Can Use It - **The Coding Way**: I'll be honest - you need to be comfortable with programming for this one. It's perfect if you're already a developer or data engineer who loves to code. But think about LLMs, they are getting better and better at generating code every week. - **The Drag-and-Drop Way**: This is way more accessible. Whether you're a business analyst, marketer, or just someone who needs to crunch some numbers, you can jump right in without any coding background. ### Working Together - **The Coding Way**: This is where it gets interesting! It's like having a shared document where every change is tracked. You can see who changed what, when, and why - super helpful when working in teams. - **The Drag-and-Drop Way**: While you can definitely share your dashboards and reports, it's not quite as sophisticated when it comes to tracking changes. It's more like sending files back and forth. ### Making It Your Own - **The Coding Way**: The sky's the limit here! Since you're writing code, you can customize pretty much everything. I love this about coding - if you can dream it, you can probably build it. - **The Drag-and-Drop Way**: It's kind of like using templates - super quick to get started, but sometimes you might hit a wall when trying to do something really specific. ![Drag and Drop Interface](/blog/dnd-1.jpg) ### Getting It Out There - **The Coding Way**: This is pretty slick - you can automate everything using CI/CD pipelines. It's like having a robot assistant that handles all the deployment stuff for you. - **The Drag-and-Drop Way**: It's usually more hands-on when it comes to deployment. Though I've noticed some tools are getting better at this lately. ## My Take Here's what I think: neither approach is inherently better - it really depends on what you need. If you're a team of developers who love to code and need tons of customization, the coding approach might be your jam. But if you want something quick and easy that anyone can use, drag-and-drop tools are still fantastic. The key is to be honest about your team's skills, what kind of data complexity you're dealing with, and how much customization you really need. I've seen both approaches work brilliantly when used in the right context. Thinking about a future with AI tools, I think the BI as code approach will be the one that will benefit the most from this. You all probably can understand that AI tools are getting better and better at generating code. I'm curious to see how this will evolve in the future. What do you think?

Building Data and Digital Solutions

Latest Articles

The Art of Prompt Engineering

UIkit and Evidence

Observable Framework