Are Strict Data Conventions Helpful or Overkill?

Main topic

The video argues that strict data conventions (naming rules, modeling standards, and structure) in a data warehouse/data modeling setup are generally helpful rather than overkill—especially with a dbt-centric workflow using tools like Snowflake and GitHub.

Context / scenario described

• A client team is moving to a dbt-centric, process/modeling approach.
• They’re building a quality foundation:
  • defining facts and dimensions
  • agreeing on naming conventions
  • deciding when to use intermediate models, macros, and other dbt constructs
• The standards are intended not only for the current team, but for the wider organization that will adopt the tooling later.

Key reasons strict conventions are valuable

1) Save time long-term (reduce “chaos”)

Without safeguards/standards, systems can become:

• chaotic and unstructured
• full of nested queries/views/stored procedures (logic stacked on top of logic)
• hard to understand and modify safely

Why it happens: teams often develop in urgency (“release fast”), and later others must maintain or extend code that only the original author fully understands. Over time, this creates:

• fear of touching code
• uncertainty about whether outputs have been wrong for years
• many “tribal knowledge” situations across the company

With conventions: code becomes more predictable (e.g., clearer facts/dimensions, data marts, sequential logic), which makes onboarding and future changes faster.

2) Improve query and code consistency (developer productivity)

The speaker emphasizes that, beyond model structure, individual queries also vary a lot when conventions aren’t enforced:

• different intervals
• different naming approaches
• different coding styles

This forces developers into a time-consuming “new world” whenever they open unfamiliar stored procedures/functions.

With conventions (consistent sections like imports / custom logic / final select, clear naming, and avoiding confusing aliases), developers can quickly understand where they are and what to change.

The speaker also notes that even small review costs (extra seconds per query) accumulate massively across many daily code reviews.

3) Scalability and easier delegation

Strict structure supports:

• explaining systems to new team members
• hiring/replacing developers
• leaders stepping away from daily development

Without standardization, knowledge gets locked in a few people’s heads, making scaling difficult and leaving projects hard to transfer.

4) Cleaner, more professional, and modular code

• Consistent conventions make logic easier to read and follow
• They reduce “house of cards” designs where nobody can confidently modify deeper parts
• They enable modularity, where changes in one place propagate through well-defined links rather than requiring edits across many scattered areas

The speaker highlights an approach: build one pipeline end-to-end as a model/example, defining rules and modeling practices for that pipeline before scaling out.

5) Personal growth and engineering pride (“perfection,” but not literal perfection)

The speaker connects conventions to:

• taking pride and building real craftsmanship/skill
• striving for excellence rather than ignoring easy shortcuts
• improving iteratively (since nobody is 100% perfect)

They argue that conventions shouldn’t be about pointless bureaucracy, but about enabling better engineering habits.

AI angle (how conventions improve AI usefulness)

The video claims clear rules/strategy make AI more effective:

• you can provide an AI assistant a style guide (naming conventions, layers, strategy)
• then ask it to generate code faster while maintaining consistency
• you can more easily review and monitor what AI does because outputs follow an agreed structure

Overall takeaway / conclusion

Setting rules and conventions is positioned as:

• an investment (not tedious overhead)
• valuable for time savings, scalability, maintainability, and skill development
• not requiring “perfect” outcomes, but encouraging continuous improvement and consistency

Main speaker / source

• The speaker is the video creator/host (no specific name is provided in the subtitles).
• The talk also references prior discussions with a client team and the host’s experience working with teams.