Disciplined Approach

methodology

Disciplined Approach

Definition

A disciplined approach to software development is a systematic methodology that imposes consistent, measurable, and enforceable standards on every aspect of the development process -- from code style and documentation to testing, deployment, and operational monitoring. Unlike ad hoc development where quality is aspirational, a disciplined approach makes quality mandatory through automated enforcement mechanisms that prevent violations from reaching production.

Discipline in software engineering is not about rigid adherence to arbitrary rules. It is about the deliberate construction of systems, processes, and culture that make correct behavior the default and incorrect behavior difficult or impossible. A truly disciplined approach automates what can be automated, documents what must be understood, tests what must be correct, and reviews what requires judgment. It recognizes that human willpower alone is insufficient to maintain quality at scale and over time, and therefore encodes quality requirements into tooling that enforces them consistently, tirelessly, and without exception.

Overview

Software projects fail for many reasons, but the most common and preventable cause is the gradual erosion of quality standards. A function is merged without tests "because it is simple." A warning is ignored "because it is not critical." A code review is skipped "because we need to ship." Each individual decision seems reasonable in isolation, but their cumulative effect is a codebase that is fragile, poorly understood, and expensive to change. A disciplined approach prevents this erosion by making the cost of quality violations immediate and unavoidable rather than deferred and uncertain.

The Prismatic Platform embodies this philosophy through its NO MERCY, NO DOUBTS doctrine -- a zero-compromise approach to code quality that pervades every layer of the platform. The doctrine is not a suggestion or a guideline; it is enforced through automated tooling (the 11-phase pre-commit hook), quality gates (13 independent quality domains), forbidden pattern detection, mandatory regression tests, and session discipline protocols. The result is a platform with a perfect 100/100 quality score across all 13 quality domains, with zero warnings, zero technical debt, and zero forbidden patterns.

The Spectrum of Engineering Discipline

Engineering discipline exists on a spectrum:

LevelDescriptionEnforcementExample
Ad HocNo standards; quality depends on individual skillNonePersonal scripts
DocumentedStandards exist as written guidelinesHonor systemTeam wikis
ReviewedStandards are checked during code reviewHuman reviewPull request checklists
AutomatedStandards are checked by CI pipelinesAutomated gatesCI/CD with linting
EnforcedStandards cannot be bypassed at any levelBlocking enforcementPrismatic Platform approach

The Prismatic Platform operates at the "Enforced" level, where quality standards are not just checked but enforced -- violations physically prevent code from reaching the repository.

Technical Details

Quality Gate Architecture

The disciplined approach is implemented through a layered quality gate system:

defmodule Prismatic.Discipline.QualityEnforcement do
  @moduledoc """
  The quality enforcement system implements the disciplined approach
  through layered, non-bypassable quality gates. Each gate evaluates
  a specific quality domain and blocks progress on failure.
  """

  @type enforcement_level :: :warning | :blocking | :critical | :supreme
  @type quality_domain :: atom()

  @type enforcement_rule :: %{
    domain: quality_domain(),
    level: enforcement_level(),
    checker: (-> {:ok, non_neg_integer()} | {:error, String.t()}),
    description: String.t()
  }

  @spec enforce(enforcement_rule()) :: :passed | {:blocked, String.t()}
  def enforce(rule) do
    case rule.checker.() do
      {:ok, 0} ->
        :passed

      {:ok, violation_count} ->
        handle_violations(rule, violation_count)

      {:error, reason} ->
        {:blocked, "#{rule.domain}: #{reason}"}
    end
  end

  @spec handle_violations(enforcement_rule(), non_neg_integer()) :: :passed | {:blocked, String.t()}
  defp handle_violations(rule, count) do
    case rule.level do
      :warning ->
        log_warning(rule.domain, count)
        :passed

      :blocking ->
        {:blocked, "#{rule.domain}: #{count} violations found (BLOCKING)"}

      :critical ->
        {:blocked, "#{rule.domain}: #{count} violations found (CRITICAL - immediate action required)"}

      :supreme ->
        {:blocked, "#{rule.domain}: #{count} violations found (SUPREME REVIEW required)"}
    end
  end

  @spec enforce_all([enforcement_rule()]) :: :all_passed | {:blocked, [String.t()]}
  def enforce_all(rules) do
    results = Enum.map(rules, &enforce/1)
    blocked = Enum.filter(results, &match?({:blocked, _}, &1))

    case blocked do
      [] -> :all_passed
      failures -> {:blocked, Enum.map(failures, fn {:blocked, msg} -> msg end)}
    end
  end
end

Forbidden Pattern Detection

A key component of the disciplined approach is the automated detection and blocking of anti-patterns:

defmodule Prismatic.Discipline.ForbiddenPatterns do
  @moduledoc """
  Scans the codebase for forbidden patterns that violate the
  disciplined approach. Patterns include mocks in production code,
  stubs, placeholders, hardcoded values, and incomplete implementations.
  """

  @type pattern_category :: :mocks | :stubs | :placeholders | :naive | :localhost | :test_skips
  @type severity :: :block | :warn

  @type forbidden_pattern :: %{
    category: pattern_category(),
    pattern: Regex.t(),
    severity: severity(),
    scope: :lib | :test | :all,
    message: String.t()
  }

  @patterns [
    %{category: :mocks, pattern: ~r/Mox\.defmock/, severity: :block, scope: :lib,
      message: "Mox.defmock forbidden in production code"},
    %{category: :stubs, pattern: ~r/raise\s+"not implemented"/, severity: :block, scope: :lib,
      message: "Stub implementation forbidden"},
    %{category: :stubs, pattern: ~r/raise\s+:not_implemented/, severity: :block, scope: :lib,
      message: "Stub implementation forbidden"},
    %{category: :placeholders, pattern: ~r/#\s*(PLACEHOLDER|STUB|MOCK|FIXME|HACK|WORKAROUND|XXX)/, severity: :block, scope: :all,
      message: "Placeholder comments forbidden"},
    %{category: :naive, pattern: ~r/#\s*(naive|temporary|quick and dirty)/i, severity: :block, scope: :lib,
      message: "Naive/temporary implementations forbidden"},
    %{category: :localhost, pattern: ~r/"http:\/\/localhost/, severity: :warn, scope: :lib,
      message: "Hardcoded localhost URL detected"}
  ]

  @spec scan(String.t()) :: {:ok, non_neg_integer(), [map()]}
  def scan(path) do
    violations =
      @patterns
      |> Enum.flat_map(fn pattern ->
        find_violations(path, pattern)
      end)

    {:ok, length(violations), violations}
  end

  @spec find_violations(String.t(), forbidden_pattern()) :: [map()]
  defp find_violations(base_path, pattern) do
    scope_path = scope_to_path(base_path, pattern.scope)

    scope_path
    |> list_elixir_files()
    |> Enum.flat_map(fn file ->
      file
      |> File.read!()
      |> String.split("\n")
      |> Enum.with_index(1)
      |> Enum.filter(fn {line, _num} -> Regex.match?(pattern.pattern, line) end)
      |> Enum.map(fn {line, num} ->
        %{file: file, line: num, content: String.trim(line),
          category: pattern.category, severity: pattern.severity, message: pattern.message}
      end)
    end)
  end
end

Regression Test Protocol Enforcement

The disciplined approach mandates that every bug fix includes a regression test. This is enforced programmatically:

defmodule Prismatic.Discipline.RegressionProtocol do
  @moduledoc """
  Enforces the mandatory regression test protocol.
  Every bug fix commit must be accompanied by at least one
  new test that would have caught the original bug.
  """

  @type regression_report :: %{
    bug_description: String.t(),
    root_cause: String.t(),
    test_file: String.t(),
    test_name: String.t(),
    validated: boolean(),
    coverage: [String.t()]
  }

  @spec validate_bug_fix_commit(String.t()) :: :ok | {:error, String.t()}
  def validate_bug_fix_commit(commit_sha) do
    with {:ok, files} <- get_changed_files(commit_sha),
         {:ok, message} <- get_commit_message(commit_sha),
         true <- is_bug_fix?(message),
         {:ok, test_files} <- extract_test_files(files),
         :ok <- verify_new_tests_exist(test_files) do
      :ok
    else
      false ->
        :ok

      {:error, :no_test_files} ->
        {:error, "Bug fix commit #{commit_sha} has no associated test files. " <>
          "The mandatory regression test protocol requires every bug fix to include " <>
          "at least one regression test."}

      {:error, :no_new_tests} ->
        {:error, "Bug fix commit #{commit_sha} modifies test files but adds no new tests. " <>
          "At least one new test case must be added that would have caught the original bug."}

      {:error, reason} ->
        {:error, "Regression protocol validation failed: #{reason}"}
    end
  end

  @spec is_bug_fix?(String.t()) :: boolean()
  defp is_bug_fix?(message) do
    String.starts_with?(message, "fix") or
      String.contains?(message, "bug") or
      String.contains?(message, "regression")
  end

  @spec verify_new_tests_exist([String.t()]) :: :ok | {:error, atom()}
  defp verify_new_tests_exist([]), do: {:error, :no_test_files}

  defp verify_new_tests_exist(test_files) do
    has_new_tests =
      Enum.any?(test_files, fn file ->
        {additions, _deletions} = count_diff_lines(file)
        additions > 0
      end)

    if has_new_tests, do: :ok, else: {:error, :no_new_tests}
  end
end

Documentation Coverage Enforcement

The disciplined approach requires comprehensive documentation:

defmodule Prismatic.Discipline.DocumentationCoverage do
  @moduledoc """
  Enforces documentation coverage requirements. Every public module
  must have @moduledoc, every public function must have @doc and @spec.
  """

  @type coverage_report :: %{
    total_modules: non_neg_integer(),
    documented_modules: non_neg_integer(),
    total_functions: non_neg_integer(),
    documented_functions: non_neg_integer(),
    total_specs: non_neg_integer(),
    coverage_percentage: float()
  }

  @spec check_module(module()) :: {:ok, :fully_documented} | {:error, [String.t()]}
  def check_module(module) do
    issues = []

    issues =
      case Code.fetch_docs(module) do
        {:docs_v1, _, _, _, :hidden, _, _} -> issues
        {:docs_v1, _, _, _, %{"en" => _doc}, _, _} -> issues
        _ -> ["Missing @moduledoc for #{inspect(module)}" | issues]
      end

    issues =
      module.__info__(:functions)
      |> Enum.reduce(issues, fn {func, arity}, acc ->
        case function_documented?(module, func, arity) do
          true -> acc
          false -> ["Missing @doc for #{inspect(module)}.#{func}/#{arity}" | acc]
        end
      end)

    issues =
      module.__info__(:functions)
      |> Enum.reduce(issues, fn {func, arity}, acc ->
        case function_has_spec?(module, func, arity) do
          true -> acc
          false -> ["Missing @spec for #{inspect(module)}.#{func}/#{arity}" | acc]
        end
      end)

    case issues do
      [] -> {:ok, :fully_documented}
      issues -> {:error, Enum.reverse(issues)}
    end
  end
end

Implementation in Prismatic Platform

The NO MERCY, NO DOUBTS Doctrine

The Prismatic Platform's disciplined approach is codified in the NO MERCY, NO DOUBTS doctrine. "No Mercy" means zero tolerance for incomplete implementations, quality violations, and untested code. "No Doubts" means full investigation before acting, decisive execution once committed, and verified results with evidence. This doctrine is not aspirational -- it is enforced through every layer of the development workflow.

100/100 Quality Score Achievement

The platform maintains a perfect 100/100 quality score across all 13 quality domains. This was achieved through systematic elimination of 905 quality debt points (QDP) and the establishment of automated enforcement that prevents new quality debt from accumulating. The quality score has been maintained at 100/100 since its achievement.

Zero-Warning Compilation

The --warnings-as-errors flag is mandatory on all compilation. No Elixir warning, no matter how minor, is permitted. This eliminates the broken-window effect where a few warnings lead to many warnings lead to ignored warnings lead to real bugs hidden among warnings.

Complete Test Coverage

Every code path has corresponding test coverage. The platform runs unit tests, integration tests, and property-based tests as part of the standard development workflow. Test coverage is tracked per application through quality DNA files.

Session Discipline Protocol

Every development session follows a prescribed protocol: create GitLab tickets, commit atomically and frequently, push immediately, test locally before committing, pass all hooks without bypass, and save session context. This protocol is enforced through the SessionLifecycle GenServer with circuit breaker protection.

Comparison with Alternatives

Disciplined Approach vs. "Move Fast and Break Things"

The "move fast and break things" philosophy prioritizes speed of iteration over code quality, accepting that some breakage is the cost of velocity. The disciplined approach argues that speed and quality are not in tension: automated quality enforcement runs in seconds, and the time saved by preventing bugs far exceeds the time spent on quality checks. The Prismatic Platform's pre-commit hook runs in under 5 minutes; a single production incident can cost hours or days.

Disciplined Approach vs. "Good Enough" Engineering

"Good enough" engineering deliberately accepts imperfection to ship faster, planning to improve quality later. The disciplined approach recognizes that "later" rarely comes, and that the cost of remediation grows exponentially with the age of the defect. Technical debt that is easy to fix today becomes deeply embedded tomorrow.

Disciplined Approach vs. Bureaucratic Process

Excessive process (mandatory design documents, change advisory boards, multi-level approvals) can slow development without improving quality. The disciplined approach automates quality enforcement rather than adding human review layers. Automated gates are faster, more consistent, and less susceptible to social pressure than human reviewers.

Formal Methods vs. Practical Discipline

Formal verification (Lean4, TLA+, Coq) provides mathematical guarantees of correctness but is expensive to apply universally. The disciplined approach uses formal methods selectively (the Trinity Gate's formal necessity check) while relying on automated testing, static analysis, and code review for the broader codebase. This pragmatic combination provides strong quality guarantees without the overhead of full formal verification.

Best Practices

  1. Encode Standards in Tooling: Every coding standard that can be checked automatically should be checked automatically. Human willpower degrades under pressure; automated checks do not.

  2. Make Violations Impossible, Not Just Detectable: Where possible, design systems so that violations cannot occur. Use type systems, restricted APIs, and compile-time checks to prevent errors rather than detect them.

  3. Start Strict, Relax Deliberately: It is easier to relax an overly strict standard than to tighten a lax one. Begin with the strictest reasonable standards and make justified exceptions, rather than starting permissive and trying to add discipline later.

  4. Measure and Display Quality Metrics: Visible metrics create accountability. The Prismatic Platform's quality score (100/100), QDP count (0), and warning count (0) are prominently displayed, creating social reinforcement for maintaining standards.

  5. Apply Discipline Uniformly: Quality standards that apply only to certain teams, certain applications, or certain types of changes are ineffective. The Prismatic Platform applies the same 11-phase pre-commit hook to all 115 umbrella applications.

  6. Automate the Boring Parts: Formatting, linting, import ordering, and documentation format checking should never require human attention. The mix format, mix credo, and documentation coverage tools handle these mechanically.

  7. Invest in Fast Feedback Loops: The faster a developer learns about a quality violation, the cheaper it is to fix. Local pre-commit hooks provide faster feedback than CI pipelines, which provide faster feedback than code review, which provides faster feedback than production incidents.

  8. Document the "Why" of Every Rule: Developers comply more willingly with rules they understand. Every quality gate, forbidden pattern, and workflow requirement in the Prismatic Platform is documented with its rationale in the corresponding policy file.

Common Pitfalls

  1. Discipline Without Automation: Relying on developers to manually follow checklists and guidelines degrades quickly under time pressure. Automation is the only reliable enforcement mechanism.

  2. Inconsistent Enforcement: Applying quality standards to some code but not others creates a two-tier codebase. The undisciplined portion eventually contaminates the disciplined portion.

  3. Discipline as Punishment: If quality enforcement is perceived as punishment rather than support, developers will find ways to circumvent it. Frame discipline as a tool that protects developers from their own mistakes and their colleagues' mistakes.

  4. Over-Rigidity: Discipline must serve the goal of producing good software, not become an end in itself. If a rule consistently produces false positives or blocks legitimate code, the rule should be refined.

  5. Ignoring Developer Experience: Quality gates that take 30 minutes to run or produce incomprehensible error messages undermine the disciplined approach. Invest in speed and clarity of enforcement tools.

  6. Discipline Fatigue: Constantly adding new rules without removing obsolete ones creates fatigue and resentment. Periodically review and prune the rule set to maintain focus on rules that provide genuine value.

  7. Confusing Activity with Discipline: Running many tools is not the same as having a disciplined approach. The tools must be configured correctly, their outputs must be acted upon, and their enforcement must be non-bypassable.

Use Cases

Large-Scale Platform Development

The Prismatic Platform's 115 umbrella applications, 530+ agents, and ~2.8M lines of code would be unmanageable without a disciplined approach. Automated quality enforcement ensures consistent quality across the entire codebase regardless of which developer makes the change.

Regulatory Compliance

Financial services, healthcare, and government software must demonstrate compliance with regulatory standards. A disciplined approach with automated enforcement and comprehensive audit trails provides the documentation needed for compliance certifications (SOC2, ISO 27001, NIS2).

Open Source Project Quality

Open source projects that accept contributions from developers with varying skill levels need automated quality enforcement to maintain consistent quality. The Prismatic Platform's quality gates ensure that all contributions, whether from the core team or from community contributors, meet the same standards.

High-Reliability Systems

Systems where failures have significant consequences (security platforms, financial systems, infrastructure automation) benefit most from a disciplined approach. The Prismatic Platform's OSINT and security assessment features require high reliability because incorrect intelligence analysis can lead to wrong decisions.

Team Scaling

As teams grow, informal quality practices break down. A disciplined approach with automated enforcement maintains quality even as new team members join who may not yet understand all the conventions. The tooling teaches and enforces standards simultaneously.

The disciplined approach draws from and connects to many platform concepts:

  • No Mercy No Doubts -- The foundational doctrine that demands zero tolerance for quality violations and evidence-based execution
  • Quality Gates -- The automated checkpoints that enforce the disciplined approach across 13 quality domains
  • Zero Tolerance -- The policy of rejecting any code that does not meet all quality standards
  • Code Quality -- The measurable attributes of source code that the disciplined approach seeks to maximize
  • Testing -- The verification methodology that provides evidence of correctness
  • Pre-Commit Hooks -- The local enforcement mechanism that catches violations before they leave the developer's machine
  • Static Analysis -- The compile-time code analysis that detects potential issues without executing the code
  • Regression Testing -- The mandatory protocol that ensures every bug fix includes tests to prevent recurrence
  • Clean Run -- The zero-warning compilation requirement that prevents warning accumulation
  • Zero Warning Policy -- The specific policy requiring zero compilation warnings across all applications

See Also

  • Quality DNA -- The cross-session quality metric tracking system that records quality over time
  • Quality Floor Guardian -- The autonomous quality monitoring system that detects and responds to quality degradation
  • Automate Relentlessly -- The principle of automating all automatable quality checks
  • Zero Compromise Quality -- The standard that rejects any compromise on quality for speed
  • Doctrine -- The broader doctrine framework within which the disciplined approach operates

Connect & Contribute

Created by Tomas Korcak (korczis) | Open Source under GHL

Back to Glossary