> Markdown version of [/videos/678-the-name-of-the-rose](https://www.wearedevelopers.com/videos/678-the-name-of-the-rose). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# The Name of the Rose

Repurposing a single-letter flag once triggered a massive financial catastrophe. Discover how context-aware naming and domain-driven design prevent costly bugs and reduce developer cognitive load.

- **Speakers:** Reka Horvath
- **Event:** World Congress 2023
- **Published:** September 21, 2023
- **Duration:** 28:40
- **URL:** https://www.wearedevelopers.com/videos/678-the-name-of-the-rose

## Summary

Code is read using the same cognitive processes as natural language, meaning the names chosen for functions and variables fundamentally frame a developer's understanding of a system's domain. When interacting with a codebase, context-aware naming reduces cognitive load and mitigates the risk of costly bugs. Conversely, misleading names—such as getters with hidden side effects or terms experiencing semantic drift—obscure intent and can cause catastrophic sequence failures. A striking historical example involves a deployment disaster where repurposing a single-letter flag for a deprecated feature contributed to a massive financial loss, highlighting the compound danger of outdated naming and technical debt. To build intuitive and maintainable software, developers should strive for a strict one-to-one mapping between source code descriptors and real-world domain concepts. This involves avoiding localized synonyms for identical ideas and rejecting overloaded terms that fracture meaning. Context plays a crucial role in these decisions; effective interfaces, such as those found in modern HTTP libraries, demonstrate how aligning method labels with standard architectural nomenclature provides immediate clarity for both domain experts and newcomers. Ultimately, maintaining codebase clarity requires continuously reevaluating semantics as a project's architecture, frameworks, or business requirements evolve. Adopting practices from domain-driven design, such as establishing a ubiquitous language across technical execution and product materials, ensures terminology remains accurate. By prioritizing descriptive, context-specific identities over generic industry phrases, engineering teams can streamline onboarding, improve cross-functional coordination, and build exceptionally resilient systems.

**Keywords:** code naming conventions, cognitive load in programming, misleading function patterns, api design consistency, domain-driven design, ubiquitous language, semantic drift in codebase, legacy code refactoring, python requests library, django exception naming, one-to-one domain mapping, automated pair programming, knight capital deployment bug, software technical debt, clean code practices

## Chapters

1. **Introducing complex domains through descriptive code naming** (00:04) — Comparing opaque code against descriptive classes demonstrates how naming documents business rules directly.
1. **Automating code quality with large language models** (02:26) — Integrating large language models into pair programming tools helps developers pick better variable names automatically.
1. **Applying human language processing to reading code** (03:32) — Recognizing that developers read code like text helps teams direct attention using strategic naming patterns.
1. **Avoiding misleading names and unexpected side effects** (05:21) — Hiding unintended side effects behind standard verbs prevents developers from noticing critical state changes.
1. **Replacing generic verbs with descriptive compound names** (08:38) — Replacing overly generic verbs with specific compound terminology clarifies what complex background functions execute.
1. **Mapping specific names to single real world concepts** (10:27) — Enforcing a one-to-one mapping between system entities and business terminology eliminates the risk of synonym confusion.
1. **Analyzing how outdated feature flags cause system failures** (14:26) — Leaving legacy single-letter feature flags in production systems can accidentally trigger catastrophic deployment errors.
1. **Designing consistent interfaces using domain specific nomenclature** (17:34) — Adopting familiar standardized nomenclature from existing protocols and libraries dramatically improves new API discoverability.
1. **Reevaluating variable names when business requirements change** (22:28) — Failing to update obsolete terminology when business requirements change fractures the integrity of domain-driven design.
1. **Managing codebase conceptual changes during ongoing implementation** (26:14) — Overcoming the friction to update variable names later requires enforcing ongoing adjustments as implementation details evolve.

## Related Moments

- [Applying patterns and principles to maintain code analyzability](https://www.wearedevelopers.com/videos/1684-modern-software-architectures) (from "Modern software architectures")
- [Improving communication while defending foundational code quality](https://www.wearedevelopers.com/videos/1438-why-most-software-projects-fail-silently) (from "Why (most) software projects fail silently...")
- [Writing precise titles and active decisions for architectural searchability](https://www.wearedevelopers.com/videos/48-work-efficiently-with-architecture-decision-records-adrs) (from "Work efficiently with Architecture Decision Records (ADRs)")
- [Debunking the myth of self-documenting code](https://www.wearedevelopers.com/videos/681-technical-documentation-how-can-i-write-them-better-and-why-should-i-care) (from "Technical Documentation - How Can I Write Them Better and Why Should I Care?")
- [Cultivating code comprehension over cargo cult programming](https://www.wearedevelopers.com/videos/235-antipatterns-nemesis-of-software-development) (from "Antipatterns - nemesis of software development")
- [Establishing core principles for data focus and naming](https://www.wearedevelopers.com/videos/33-api-design-getting-started) (from "API Design - Getting Started")

## Related Articles

- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)
- [Dev Digest 138 - Are you secure about this?](https://www.wearedevelopers.com/magazine/486-dev-digest-138-are-you-secure-about-this)
- [The real reason we document our code](https://www.wearedevelopers.com/magazine/518-the-real-reason-we-document-our-code)
- [Dev Digest 137 - AI'm not sure about this](https://www.wearedevelopers.com/magazine/485-dev-digest-137-ai-m-not-sure-about-this)

## Related Jobs

- [Tribe Lead - ( Software) Engineering Centre of Excllence](https://www.wearedevelopers.com/jobs/ext/1475530-tribe-lead-software-engineering-centre-of-excllence) at **SD Worx**
- [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub**
- [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/15942-senior-software-engineer) at **GitHub**
- [Principal Software Engineer, Identity](https://www.wearedevelopers.com/jobs/ext/1469181-principal-software-engineer-identity) at **GitHub**
- [Senior Software Engineer, Enterprise Products](https://www.wearedevelopers.com/jobs/ext/1841248-senior-software-engineer-enterprise-products) at **GitHub**
- [Machine Learning Engineer](https://www.wearedevelopers.com/jobs/ext/1597388-machine-learning-engineer) at **ZEISS Group**