Are Strict Data Conventions Helpful or Overkill?

Strict data conventions are helpful, and for most small teams they are not overkill. A convention is an agreed rule for how you name objects, structure queries and move work through the pipeline, so that everyone's work looks like it came from the same team. The cost of not having them shows up slowly: nested queries nobody understands, logic locked in one person's head, and five extra seconds of decoding on every file you open. The payoff is the reverse of that: less time getting oriented, a team that can scale past its original developer, and work you can be proud of. The right level of strictness is the one you can write down and follow consistently, not perfection.

Where this question came from

There is a lot of material out there on best practices for building a data warehouse, including mine. The question I hear often is: how strict do we really need to be? At what point does it become overkill, and what is the realistic downside of not following the rules perfectly?

This came up recently with a client whose team is moving to a dbt centric process. They have dbt, Snowflake and GitHub, which is a solid setup, and they are building the foundation now.

Together we had already done a lot of the groundwork:

• Facts and dimensions. We defined the core fct_ and dim_ models.
• Naming rules. We set conventions for objects, queries and the workflow around them.
• When to use what. We discussed when an intermediate model makes sense, when a macro makes sense, and so on.

They also want this foundation to serve the rest of the organization, not just the data team. So with a lot of scripts to migrate, the question was how specific they need to be and why it matters. Here is the feedback I gave them.

Reason 1: It saves time in the long run

Without safeguards, you end up with chaos. Nested queries, views built on views, stored procedures that call other stored procedures. If you have been in this field long enough you have seen it, and you know how hard it is to understand what is going on.

How the mess gets built

It usually starts with a team in a hurry. Someone needs a result fast, so they write a query. That person is probably the only one who understands the logic.

Later they leave, or someone else has to extend it. The new person doesn't want to break what works, so they write a new query on top of the old one. Over the years you get nested versions of everything.

Eventually the logic is stacked so deep that everyone is afraid to touch it. You don't even know if it has been returning wrong results for years. Many teams have dozens of these scenarios across the company.

Nobody did this on purpose. It's simply what happens when there are no rules, agreements or standards to follow.

What the time actually costs

When a developer needs to change one of those nested procedures, they spend a huge amount of time just figuring out what's what before they can add anything. That analysis time has a real price.

Compare that to a clear structure: a staging layer, an intermediate layer, facts and dimensions, marts, and logic placed in sequence. Getting up to speed takes a fraction of the time, and ideally it's the same across every piece of work.

Query design matters too

This isn't only about how the model or pipeline is structured. It's also about how each individual query is written. When every query uses different indentation, different naming and a different layout, each one takes longer to read.

I remember this from my very first team. Every time I opened a new stored procedure it was like entering a new world. Nobody's style was better than anyone else's, it was just extremely inconsistent.

The alternative is a shared layout. Imports at the top, custom logic in the middle, a final select at the bottom. Full names or clear aliases instead of single letters. Small things, but you get your bearings immediately.

It sounds boring, and it adds up. An extra 5 seconds on one query, 10 on another, 20 on the next, multiplied across every query every day. That compounds on its own, and clarity turns it in your favor.

Reason 2: Scalability

When the rules are in place and understood, explaining the work to someone else becomes much easier. That matters the moment the original builder is unavailable.

Replacing yourself

I meet a lot of team leads who still do most of the development themselves and want to step back into management. If the process was built situationally, on a whim, it's very hard to hand off. Too much of it lives in your head.

The same thing happens with one or two developers who own everything and build it their own way. That's the classic case of tribal knowledge: the logic and the understanding are locked in a few minds, or one.

If you want the system to scale, or want to replace yourself or anyone else on the team, for good reasons or bad, the work has to be consistent. You decide that in advance.

Cleaner code and modularity

Conventions also push you toward cleaner code. It reads more professionally, so you spend less time analyzing and more time following and extending the logic.

The nested procedure scenario is the opposite: a house of cards where you hope nobody looks under the hood. We have all built one. I'm not blaming anyone, I've done it too. It just doesn't scale.

Thinking through the rules also makes your work more modular. Modularity means logic is isolated where it belongs, at the most granular level, so a change in one place flows through everything that references it instead of being patched in ten places.

Start with one pipeline

This is why I push teams to build one pipeline from start to finish before anything else. Not the whole project, not all the data. One pipeline where we define the rules, discuss the modeling and walk through the scenarios.

That pipeline becomes the example. When you start moving other data and logic into the new process, the pattern is already proven.

Reason 3: Excellence

The last reason is about you as an individual: your career, and the precedent you set if you lead the team. The word I use is excellence, and what I mean is real pride in your work.

This is a skill set you can develop, and it's what you do every day. So why not try to be good at it? Not the Michael Jordan of data engineering, but with a genuine desire to do the job well.

For me that means modeling data properly, thinking about the rules, creating naming standards, seeing the bigger picture and making the implementation as high quality as you can. That's just part of being an engineer.

The easy way becomes a crutch

It would be easier, and very tempting, to ignore the rules and get it over with faster. At a certain point that becomes a crutch that prevents you from improving. You do what's easy because it's convenient.

Working through the conventions forces you to understand them, analyze the problem and apply the answer. That makes you a better developer, engineer or leader, whatever your title.

Not perfection, progress

None of this is about being 100 percent perfect, because nobody is. We have all implemented something carefully and then seen afterward what could have been a little better. That's fine. You took the step instead of starting from nothing and getting nowhere.

It's gradual learning, which is why more than one opinion on the team helps, and why an outside perspective to validate the approach is useful. The work is never finished. You're always improving.

A note on AI

We can't talk about data in 2026 without mentioning AI, so here is the one point that belongs in this conversation.

Clear rules make AI far more effective. When you have thought through naming conventions, layers and strategy and formalized them into a style guide, you can hand that guide to an AI assistant along with the task.

The result is much more consistent output, whether the AI is doing the work or you are reviewing it. You can follow what it did instead of getting lost in decisions it made on its own. Without the rules, you have handed over the thinking too.

Related reading

• Why Bother With Naming Conventions?
• The Power of Naming in Data Projects (especially w/ dbt)
• dbt Project Naming Conventions: Recommendations
• The Art of Data Team Workflows

Final takeaway

This is the feedback I give clients when we set the rules for their first dbt pipeline: the conventions are what let the team move faster, hand work off and trust what they built. Define them, write them down and strive to follow them. Nobody gets it perfect, and that was never the point.