Table-driven metrics not code #substack #shorts

And you hit on a key point there too, I think. Like, I'm a big fan of table-driven architecture, right? Where you're storing things in a table as opposed to storing them in code. It's just architecturally, I feel like it's more business-friendly too, right? It's just, especially when you're even outside of calendars and dates, like KPIs and metrics, right? Calculations for KPIs and metrics. are always in flux. Those are things that are living, and you need to be able to track them to your point over time, right? Of, okay, this metric was this between this date and this date, or this KPI was this between this date. I've even built tools where we layer in an interface for the business so that they could add and adjust KPIs. As they need them. That way, it's not a full software development lifecycle. That way, the data team doesn't get blamed for being the bottleneck in the process of creating a KPI that the business wants to track.