Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Best Current Practice

Concept

Vocabulary that names a phenomenon worth recognizing and understanding.

A best current practice is a recommendation that reflects what the community knows today, with the built-in expectation that it will change as understanding improves.

Also known as: BCP, Recommended Practice

Understand This First

  • Refactor – refactoring is what you do when a practice you followed is no longer current.

What It Is

Every field has advice that sounds permanent but isn’t. “Always normalize your database.” “Never use global variables.” “Write unit tests for every function.” Each of these was true enough when it was written, in the context where it was written. Some remain solid. Others have been quietly revised or abandoned as tools, constraints, and understanding evolved.

A best current practice (BCP) is a recommendation that carries its own expiration warning. It says: this is the best we know right now, and we expect to learn more. “Best practice” without the “current” qualifier implies a finished answer, a rule you can follow forever without checking whether it still holds. BCP thinking rejects that framing. It treats every recommendation as provisional, grounded in evidence, and open to revision.

The term originated with the Internet Engineering Task Force (IETF), which created the BCP document series in 1995. The IETF needed a way to publish operational guidance that could evolve faster than formal standards. RFCs that define protocols (like HTTP or TCP) aim for stability. BCPs capture what operators have learned about running networks, managing addresses, and handling security incidents. When the community learns something new, the BCP gets updated. The old version doesn’t become wrong in retrospect. It was the best answer at the time.

Why It Matters

Software construction is full of advice that treats current fashion as permanent truth. Design patterns from 2005 get taught as eternal law. Testing practices from 2015 are treated as settled. The field moves anyway. New tools change what’s practical. New research invalidates old assumptions. New failure modes emerge as systems grow.

BCP thinking protects you from two traps. The first is treating guidance as gospel — adopting a practice because an authority said so, then following it rigidly even after conditions change. The second is treating guidance as arbitrary opinion: dismissing all recommendations because “it depends” and building from scratch every time. BCP offers a middle path. Take the recommendation seriously because it represents real experience. Hold it loosely enough to let go when the evidence shifts.

In agentic coding, this has practical consequences. AI agents are trained on text from specific time periods. An agent trained on data from 2024 may recommend practices that were current then but have since been superseded. It won’t flag its own advice as stale because it can’t. The human directing the agent needs BCP awareness to ask: Is this still the recommended approach? Has anything changed since this was written?

How to Recognize It

You’re engaging in BCP thinking when you ask any of these questions:

  • When was this advice written, and has the context changed since then?
  • What evidence supports this recommendation? Is the evidence still valid?
  • Who follows this practice today, and have they reported problems with it?
  • What would have to change for this recommendation to become wrong?

You’re ignoring BCP thinking when you:

  • Copy a practice from a tutorial without checking its date or context.
  • Defend a habit with “that’s how we’ve always done it.”
  • Reject new evidence because it contradicts an established recommendation.
  • Tell an agent to follow a pattern without verifying it still applies.

How It Plays Out

A team adopts test-driven development in 2020, following Kent Beck’s classic red-green-refactor cycle for every piece of code. By 2026, they’re using coding agents for most implementation. The agents generate code that passes specifications, and the team runs a verification loop after each change. A junior developer asks why they still write tests before code when the agent writes both the code and the tests.

The team lead explains: TDD was a best current practice for human-driven development, where writing the test first forced the developer to think about design. With an agent handling implementation, the forcing function has shifted. The team updates their practice: they write acceptance criteria before prompting the agent, let the agent generate both code and tests, then review both. The principle behind TDD — think before you build — survives. The specific ritual adapts.

A developer asks an agent to structure a new project. The agent generates a microservices architecture with twelve services, each with its own database. Five years ago, microservices were the standard recommendation for any project expecting growth. The developer recognizes this as a practice that was current in a specific era for specific reasons. She checks the project’s actual constraints: a three-person team, modest traffic, a tight launch deadline. She directs the agent to build a monolith with clean module boundaries, knowing she can extract services later if traffic demands it. The agent’s recommendation wasn’t wrong in general. It was the best practice of a particular moment, applied to a context where it no longer fits.

Consequences

Once you internalize BCP thinking, you stop looking for permanent answers and start looking for currently-good-enough answers backed by evidence. This makes you more adaptive, because you’ve pre-accepted that practices will change. It also makes you more rigorous, because “best current practice” demands you know why a recommendation is current, not just that someone authoritative said it.

The risk is analysis paralysis. If every practice is provisional, you might hesitate to commit to any of them. BCP thinking doesn’t mean questioning everything all the time. Follow the current recommendation while remaining open to new evidence. Most of the time, the current practice is good enough. When it isn’t, you’ll notice — the evidence will change, the tools will change, or the failures will pile up.

For teams directing agents, BCP awareness creates a habit of checking dates. Is this Stack Overflow answer from 2019? Is this framework recommendation from before the API redesign? Is this security guidance from before the new vulnerability class was discovered? Agents can’t perform these checks on their own. The person who understands that practices evolve is the one who catches stale advice before it causes damage.

  • Depends on: Refactor – when a BCP changes, refactoring brings existing code in line with the new recommendation.
  • Informed by: Steering Loop – steering loops are the feedback mechanism that detects when a practice has drifted from current standards.
  • Related: Instruction File – instruction files encode BCPs for agents and need updating as those practices evolve.
  • Related: Harnessability – a harnessable codebase makes it easier to adopt new practices when old ones are superseded.
  • Contrasts with: Smell (Code Smell) – yesterday’s best current practice can become today’s code smell when the context changes.
  • Related: Technical Debt – following outdated practices accumulates debt that compounds over time.

Sources

The Internet Engineering Task Force created the BCP document series in RFC 1818 (1995) to capture operational guidance that needed to evolve faster than formal standards. The series now contains over 230 documents covering topics from network operations to security incident handling.

The distinction between “best practice” and “best current practice” draws on the broader philosophy of provisional knowledge in engineering. W. Edwards Deming’s management philosophy, particularly the Plan-Do-Study-Act cycle, treats every improvement as an experiment whose results may revise the practice.