Naming things is treated like a software joke because it is safer than admitting how much delivery depends on it.
"Integration" can mean mergers and acquisitions to a COO and APIs to an engineer. "Account" can mean one thing to sales and another to the database. "Contract" can mean a legal document, a service boundary, or, if the codebase has suffered enough, a contract contract.
That ambiguity is not semantic trivia. It becomes rework.
Domain-Driven Design calls the answer ubiquitous language, which is a helpful idea saddled with a phrase only a software architect could love. The point is simple enough: business and technology teams need shared vocabulary before they can share intent.
Engineers should usually move toward the language of the business, not force the business into implementation vocabulary. The system exists to model work people already understand. If the code names the wrong thing, or names the right thing in a way nobody recognizes, confusion becomes permanent enough to compile.
Acronyms make this worse. ETL and ELT are different ideas. ELT is also an executive leadership team. Context saves you until it does not.
Shared language is delivery infrastructure. It is cheaper than another reconciliation meeting and less painful than discovering two teams were right in incompatible ways.
Related episode: Shared Language or Shared Chaos: Why Words Matter.
