Primary Depth-First Development (PDFD)

Updated 9 July 2026

Primary Depth-First Development (PDFD) is a software engineering methodology that completes one full feature path end-to-end before initiating adjacent paths.
It models software requirements as a directed acyclic graph or tree, using nodes and control parameters to enforce bounded refinement and state transitions.
PDFD excels in delivering early vertical slices and isolating risks but may lead to redundant rework when scaling breadth and promoting reuse.

Searching arXiv for papers on Primary Depth-First Development and related terminology. Primary Depth-First Development (PDFD) is a software engineering methodology that models full-stack implementation on the logic of depth-first search: a single application path is taken from root to leaf and completed end-to-end before adjacent paths are developed. In the cited arXiv literature, PDFD is defined as a primarily depth-first but selectively hybrid process—“Primary DFD (PDFD) focuses on DFD, with occasional BFD or CDD at certain levels”—and is later formalized as a hierarchical, layered, directed-graph workflow with bounded refinement, deadlock freedom, and structural completeness guarantees (Liu, 18 Jan 2025, Liu, 18 Aug 2025).

1. Definition and conceptual scope

PDFD treats software structure or requirements as a tree or Directed Acyclic Graph (DAG), with nodes denoting tasks, features, modules, or data entities, and edges denoting hierarchical relationships, dependencies, or flow. Its central rule is path-oriented completion: one path is developed deeply across all relevant layers—front-end, business logic, and database—before development proceeds to the next path. The “Primary” qualifier indicates that depth-first progression is the default control strategy, but breadth-first development (BFD) or cyclic directed development (CDD) may be inserted at selected levels when shared functionality, demonstrations, or iterative correction require it (Liu, 18 Jan 2025).

The methodology is presented as especially natural for hierarchically structured business problems. The literature illustrates this with a “places visited” hierarchy, modeled as a tree or DAG, in which a path such as Continents → North America → United States → Maryland → Howard County → Ellicott City is implemented fully before adjacent branches are taken up. This places PDFD close to the familiar notion of a vertical slice in agile practice, but the cited work frames it more explicitly in graph-theoretic and workflow terms than conventional agile descriptions do (Liu, 18 Jan 2025).

Within the same source corpus, depth-first search also appears in graph algorithms, succinct graph encodings, energy-constrained exploration, and stack-based Monte Carlo implementations. Those works concern traversal strategies or data structures rather than the software-engineering methodology explicitly called Primary Depth-First Development. The explicit methodological definition of PDFD appears in the full-stack development papers, not in the DFS algorithm papers (Ghaffari et al., 2023, Das et al., 2017, Elberfeld et al., 28 Apr 2025, Braams, 8 Jun 2026).

2. Graph-theoretic representation and control parameters

A later formalization models PDFD as a hierarchical, layered, directed graph $G=(V,E)$ , or equivalently a rooted tree with levels $L$ . Nodes represent structural entities such as modules, features, and data entities; edges represent parent-child relations. Each node $n$ carries a processing state $P(n) \in \{0,1,2\}$ , where $0$ means not yet processed, $1$ means in progress, and $2$ means finalized, validated, and complete (Liu, 18 Aug 2025).

Symbol	Meaning
$G=(V,E)$	Hierarchical, layered, directed graph or rooted tree
$P(n)\in\{0,1,2\}$	Not yet processed, in progress, finalized
$K_i$	Minimum number of finalized nodes at level $L$ 0 before progressing
$L$ 1	Maximum number of refinement cycles per level

Two control parameters define the operational discipline. First, bounded parallelism is expressed by $L$ 2: before progressing from level $L$ 3 to level $L$ 4, at least $L$ 5 nodes in level $L$ 6 must be finalized. This is described as a minimal batch or work-in-progress threshold intended to avoid premature context switching. Second, bounded refinement is expressed by $L$ 7: the number of refinement or backtracking cycles per level is strictly limited, and on validation failure at level $L$ 8, the function $L$ 9 determines the earliest failed level $n$ 0 to reprocess. Refinement then ranges over $n$ 1, subject to the $n$ 2 bound (Liu, 18 Aug 2025).

This graph-theoretic formulation reframes PDFD from an informal “build one feature deeply” heuristic into a process with explicit state, control thresholds, and rollback bounds. A plausible implication is that the methodology is intended not merely as a sequencing preference, but as a constrained execution model for hierarchical development.

3. Operational workflow and development semantics

In its procedural form, PDFD begins by mapping business requirements into an n-ary tree or a more general DAG. A developer then selects one business path and implements all layers for that path: user interface controls, business logic, and database storage. That path is tested and validated as a cohesive end-to-end unit, after which development moves to the next path. The paper’s description is explicitly sequential at the path level: depth is exhausted before breadth is expanded (Liu, 18 Jan 2025).

The methodology permits local departures from strict depth-first order. A breadth-first pass may be inserted for shared functionality at a given level, and CDD-style feedback loops may be invoked when iterative refinement is needed. Accordingly, PDFD is not defined as “pure DFS applied to software,” but as a primary depth-first regime with selective hybridization. This matters because the cited comparison with PBFD does not present the two as mutually exclusive absolutes; rather, each may borrow the other’s traversal behavior when local constraints justify it (Liu, 18 Jan 2025).

The same source gives a simple complexity characterization. Initial path development is described as $n$ 3, where $n$ 4 is the number of vertices or features. As the system grows and later paths require repeated returns to already developed points for changes or extensions, actual complexity is said to trend toward $n$ 5 because of redundancy and re-testing. The stated drawbacks are redundant rework, coding overhead, context switching, and scalability deterioration as the breadth of required features grows (Liu, 18 Jan 2025).

The formal account of PDFD specifies a parametric state machine. The principal states are $n$ 6 for initialization, $n$ 7 for processing current nodes at level $n$ 8, $n$ 9 for validation of level $P(n) \in \{0,1,2\}$ 0, $P(n) \in \{0,1,2\}$ 1 for bottom-up completion and validation of finalized subtrees, $P(n) \in \{0,1,2\}$ 2 for top-down completion of non-processed nodes, $P(n) \in \{0,1,2\}$ 3 for termination after unrecoverable error, and $P(n) \in \{0,1,2\}$ 4 for successful completion when all nodes satisfy $P(n) \in \{0,1,2\}$ 5. Simplified transitions include $P(n) \in \{0,1,2\}$ 6, $P(n) \in \{0,1,2\}$ 7, $P(n) \in \{0,1,2\}$ 8 on validation failure with remaining refinement budget, $P(n) \in \{0,1,2\}$ 9 after sufficient batch completion, and $0$0 at leaf or completion condition (Liu, 18 Aug 2025).

Formal verification is carried out with Communicating Sequential Processes (CSP) and Linear Temporal Logic (LTL), using FDR 4.2.7. The cited properties include deadlock freedom, livelock freedom, determinism with respect to environment input, protocol safety under hostile environments, and mutual exclusivity of transition guards. The paper also states total-correctness and termination properties in LTL-style form:

$0$1

and

$0$2

Bounded refinement is expressed as

$0$3

A lexicographic ranking function $0$4 is used, where $0$5 counts unfinalized nodes, $0$6 counts unused refinement attempts, $0$7 is the phase, and $0$8 is intra-phase progress; each transition is stated to decrease $0$9 strictly (Liu, 18 Aug 2025).

The bottom-up and top-down completion passes are central to the structural guarantee. Bottom-up completion validates and finalizes subtrees when leaf or blocked paths are reached; top-down completion then ensures that all remaining nodes are processed. The cited invariant is that no higher-level node is finalized unless all descendants are finalized. In the terminology of the paper, this yields structural completeness (Liu, 18 Aug 2025).

5. Relationship to PBFD and associated data representations

PBFD is presented as the principal contrasting methodology. Where PDFD completes one path deeply at a time, PBFD processes all peer features or all nodes at a given level before descending. The cited literature portrays PBFD as better suited to broad, pattern-based, level-oriented progression, while PDFD is positioned for vertical, feature-centric slices and early risk isolation. The comparison is therefore not merely between two orders of implementation, but between two different ways of amortizing reuse, validation, and schema evolution across a hierarchy (Liu, 18 Jan 2025, Liu, 18 Aug 2025).

The full-stack framework surrounding both methodologies introduces bitmask-oriented data techniques. The earlier PBFD paper states that DAG modeling, bitmaps, and elimination of junction tables produce compact and efficient data processing within relational databases. The later formal paper presents Three-Level Encapsulation (TLE), a bitmask-based encoding scheme in grandparent-parent-child units, with child relationships represented as bit positions. TLE operations are verified via CSP failures-divergences refinement, and the paper reports constant-time updates for the word-size case, with $1$0 batching otherwise. Although the later source explicitly notes that PDFD does not require TLE, it also states that the same data primitives can underpin PDFD when hierarchical state tracking is needed (Liu, 18 Jan 2025, Liu, 18 Aug 2025).

This comparative framing is important because many of the strongest storage and query metrics in the corpus are associated primarily with PBFD rather than with PDFD itself. A plausible implication is that PDFD is being positioned as part of a larger methodological family in which traversal order and representation strategy are separable design choices.

6. Empirical positioning, applicability, and limitations

The cited literature assigns PDFD a specific operational niche. It is described as suitable when a rapid, fully functioning vertical slice is needed: a minimum viable product, a proof-of-concept, a customer-critical path, or early feature-risk isolation. The later formal paper similarly states that PDFD excels in vertical, feature-centric workflows where early completion of full feature slices is needed and where deep validation before broadening scope is desirable (Liu, 18 Jan 2025, Liu, 18 Aug 2025).

At the same time, both papers emphasize its scaling limits. As adjacent or similar features accumulate, pure PDFD requires repeated returns to overlapping code and repeated regression testing, producing redundant rework and context-switching overhead. The earlier paper characterizes this as a drift toward iterative returns to prior work and compounded rework; the later paper contrasts PDFD’s bounded local parallelism with PBFD’s stronger exploitation of TLE and broad batch transitions in wide hierarchies (Liu, 18 Jan 2025, Liu, 18 Aug 2025).

The empirical performance figures most frequently associated with the framework are comparative and largely attached to PBFD deployments. One paper reports “zero bugs,” development speed improvements “of up to twenty times,” performance gains “of seven to eight times,” and storage requirements reduced “to one-eleventh compared to traditional methods” over eight years of production deployment for tens of thousands of users. The later paper reports, for PBFD, “zero critical failures,” “approximately 20x faster” development than Salesforce OmniScript, “7-8x faster query performance,” and “11.7x storage reduction” compared to conventional relational models. These figures should therefore be read as part of the broader PBFD/PDFD program, not as direct intrinsic measurements of PDFD in isolation (Liu, 18 Jan 2025, Liu, 18 Aug 2025).

Two recurrent oversimplifications are corrected by the cited sources. First, PDFD is not defined as a rigidly pure depth-first procedure; it explicitly allows occasional BFD or CDD at certain levels. Second, it is not presented only as an informal agile intuition: the later formalization casts it as a verified state machine with bounded refinement, deadlock freedom, termination, and structural completeness. Taken together, the literature presents PDFD as a depth-oriented, path-completion methodology for hierarchical full-stack systems whose principal strengths lie in end-to-end slice delivery and whose principal weakness emerges when breadth, reuse pressure, and repeated cross-branch evolution dominate (Liu, 18 Jan 2025, Liu, 18 Aug 2025).