An Inductive Criterion for the Extensibility of Information Systems

The article proposes using the principle of mathematical induction as a formal criterion for assessing the extensibility of information systems — if adding new functionality requires effort that depends primarily on the feature's own complexity rather than on the state of the system, the system is healthy. It introduces the Development Velocity Ratio (DVR) metric to quantify the slowdown of development and analyzes the technical, organizational, and psychological causes of system degradation, including the impact of AI tools on development metrics.

Článek představuje aplikaci principu... — I'll translate the full article now, preserving the paragraph structure, equations, table, and technical terminology.

---

The article presents the application of the principle of mathematical induction as an operational criterion for evaluating the extensibility of information systems. If adding the (n+1)-th feature requires comparable effort to adding the n-th, the system satisfies the induction step and is, in an idealized sense, unboundedly extensible. In practice this criterion almost never holds — systems exhibit a development-slowdown curve in which comparable functionality progressively requires an order of magnitude more time and resources. The article analyzes the causes of this slowdown — including the principled undecidability of intentional versus erroneous behavior in undocumented systems — and proposes ways to measure it. Particular attention is given to the Development Velocity Ratio (DVR) metric, from whose shape the optimal moment for refactoring can be extrapolated. The article further examines the impact of AI tools on development metrics and formulates strategies for the AI era, in which AI acts as a multiplier of existing process quality rather than as a substitute for it.

Keywords: extensibility of information systems, mathematical induction, technical debt, software aging, Development Velocity Ratio, AI-assisted development, code review, refactoring, organizational factors, psychological safety

Every experienced developer or project manager knows the following situation: in the first year of a project, the team delivered new features quickly and with relative ease. After three years, the same team needs three times as long for comparable functionality. After five years, it is ten times as long. The system is not fundamentally larger — but it is fundamentally more resistant to change.

This slowdown is so common in the field that it is considered inevitable. It has various names — software aging (Parnas, 1994), technical debt, software rot — but a simple, mathematically clean framework is missing: one that would make it possible to precisely define when a system is "healthy" and when it is not, to measure the degree of degradation quantitatively, and to extrapolate future development, including determining the point at which refactoring becomes economically necessary.

This article proposes such a framework. It is based on a simple observation: the extensibility of an information system can be tested using the principle of mathematical induction.

Mathematical induction is a proof technique consisting of two steps. The first is the base case: the statement holds for n = 1. The second is the induction step: if the statement holds for n, then it also holds for n + 1. If both conditions hold, the statement holds for all natural numbers — that is, unboundedly.

Let us reformulate the principle for the context of information systems. Base case: a system with one feature works correctly and is maintainable. Induction step: if a system with n features works correctly and is maintainable, and adding the (n+1)-th feature requires effort that depends primarily on the complexity of that feature itself (not on the state of the system) and the resulting system continues to work correctly — then the system is extensible for any finite number of features.

The key principle is the independence of effort from the state of the system. We are not saying that every feature requires the "same" effort — different features have different inherent complexity. We are saying that the effort needed to add a feature should depend primarily on the complexity of that feature itself, not on the size and state of the existing system.

A note on the limits of the analogy. "Infinite extensibility" is, of course, an idealization. A real system has external limits — hardware performance, team capacity, organizational size, the scope of the domain. The purpose of the induction criterion is not to claim that a system can be extended literally to infinity, but to distinguish systems whose limits are set by external factors from systems whose limits are set by the internal degradation of their architecture. It is precisely this second category that is the subject of this article.

Let us denote:

In an ideal system:

E(n+1) ≈ f(C(n+1))

That is, effort depends only on the complexity of the feature being added. In a real system:

E(n+1) = f(C(n+1), S(n))

That is, effort also depends on the state of the system. The degree of dependence of E on S(n) is the exact measure of the system's architectural health. If this dependence grows with increasing n, the induction step fails and the system is not unboundedly extensible.

The transition to continuous measurement. In practice we do not add features one by one in a deterministic order. Therefore, in section 4 we will move to measurement over time — we replace the discrete index n with a continuous variable t, which enables more practical measurement on real projects.

Let us imagine two concrete scenarios.

Scenario A — a healthy system: The team adds an invoice-management module. It takes 3 weeks. A year later it adds an order-management module (comparable complexity). It takes 3 weeks. The induction step holds.

Scenario B — a degrading system: The team adds an invoice-management module. It takes 3 weeks. A year later it adds an order-management module (comparable complexity). It takes 8 weeks, because 2 weeks are spent understanding the impact on existing code, 1 week fixing regressions caused by the change, 2 weeks on the actual implementation, 1 week working around the limitations of the existing architecture, and 2 weeks on testing and stabilization in the context of the whole system.

In scenario B, six of the eight weeks are unrelated to the complexity of the feature being added — they relate to the state of the system. The induction step fails.

Development slowdown does not have a single cause. It is the result of an accumulation of problems across the entire life cycle of the system. The following overview categorizes the main factors.

Technical debt is a metaphor introduced by Ward Cunningham (1992), originally for the consequences of deliberate compromises in code quality. The term has since expanded to all forms of suboptimal code — both deliberate and unintentional (Kruchten et al., 2012). Unlike financial debt, technical debt has a superlinear character — the interest grows faster than linearly, because each new compromise interacts with previous ones and creates a combinatorially growing space for problems.

Typical forms include temporary solutions that became permanent ("we'll redo it when there's time"), duplicated code instead of abstraction, circumventing architectural rules under deadline pressure, and unmaintained dependencies and libraries.

Technical debt directly increases S(n) in our formula — the state of the system becomes more complex and harder to predict with every compromise.

Documentation serves as the externalized memory of the system. Its absence means that knowledge about the system exists only in the heads of developers — and they leave, forget, or were not present when a given decision was made.

The consequences are far-reaching: every change requires an "archaeological survey" of the existing code, architectural decisions are repeatedly reconsidered because no one knows why they were made, new team members need months to get oriented in the system, and implicit dependencies remain undiscovered until they cause a production incident.

The problem of the undecidability of intentional vs. erroneous behavior. The most serious consequence of missing documentation is the principled impossibility of distinguishing a bug from a feature. If no specification of intended behavior exists, then upon finding unexpected behavior in the system one cannot, on the basis of the code and the ongoing requirements alone, decide whether it is a bug (behavior that should never have occurred and needs to be fixed), an intentional feature (behavior implemented on the basis of a requirement whose context has been lost), or emergent behavior (an unintended but useful side effect that users rely on).

This undecidability has a direct impact on the effort needed to extend the system: every change in an undocumented system first requires reconstructing intent, which is a time-consuming and principally unreliable activity. The developer must consult users, go through the ticket history, read the version history — and even then may not reach an unambiguous conclusion. In a documented system, this decision is trivial: we compare the current behavior with the specification.

The absence of documentation thus slows development not merely because the developer "does not know how the system works." It slows it more fundamentally because no one knows how the system is supposed to work. And without this knowledge, every change is a gamble — either we are fixing working functionality, or we are preserving a bug because we consider it to be intentional.

Tests are a formalized definition of the system's correct behavior. Without them a developer cannot say with certainty whether a change has broken anything, every change requires manual verification — whose time grows linearly with the size of the system — and the fear of regressions leads to defensive programming: instead of a clean solution, conditions and exceptions are added that increase complexity.

Especially destructive is the absence of regression tests — automated tests that verify that existing functionality has not been disrupted. Without them, every extension is Russian roulette.

Moreover, test coverage cannot be added retroactively with the same efficiency. Tests written after the fact test the implementation (how it works), not the specification (how it is supposed to work). They often fix erroneous behavior as correct.

Architectural decisions made at the beginning of a project have a disproportionate influence on the entire life cycle. A poor design manifests gradually.

A monolithic architecture where modularity is needed means that every change requires understanding the whole. The opposite extreme — a move to microservices — shifts complexity from code into infrastructure and network communication, and if it is not carried out at the right level of decomposition, it can paradoxically increase the effort required to extend the system.

Premature optimization means that the system is optimized for scenarios that did not occur, while at the same time it is not prepared for scenarios that did occur. Incorrect domain decomposition leads to module boundaries not matching business-domain boundaries, so that a single business change cuts across several modules. Missing layering — presentation logic mixed with business logic and data access — makes isolated changes impossible.

The choice of technology stack affects the system's maintainability for decades. Obsolete technologies — a framework without an active community means that the team solves every problem on its own. Unsuitable technologies — using a tool outside its intended deployment context (e.g., a relational database for graph data, or vice versa). Vendor lock-in — dependence on a proprietary solution that cannot be replaced without a rewrite. Insufficient automation — manual deployment, manual testing, manual environment configuration.

The analyst is a translator between the business domain and the technical implementation. Poor analysis propagates errors into all subsequent phases: incomplete analysis (uncaptured edge cases manifest as bugs in production), incorrect abstraction (the model does not match reality, so every new requirement requires working around the model), missing impact analysis (a new requirement is analyzed in isolation, without assessing its effect on existing functionality), and analytical debt (requirements implemented without proper analysis generate inconsistencies in the system).

Code is the final artifact of the entire process. Its quality directly determines maintainability: non-adherence to conventions (inconsistent naming, formatting, structure), violation of the SOLID, DRY and KISS principles (Martin, 2017), which are not academic platitudes but condensed experience, ignoring code review (unreviewed code accumulates problems superlinearly), insufficient error handling (errors propagate unpredictably), and copy-paste programming (duplication creates a maintenance burden that grows with the number of copies — each one must be found and edited separately).

Technical causes do not exist in a vacuum. The organizational context is often the primary source of degradation — and unlike technical causes, it tends to be harder to recognize, because it manifests indirectly and with a delay.

Conway's Law (Conway, 1968) states that the structure of a system mirrors the communication structure of the organization. Reorganizing a team without refactoring the system creates a mismatch — modules that are closely related are suddenly maintained by teams that do not communicate with each other.

Deadline pressure — the systematic prioritization of speed over quality. A single compromise is understandable; the problem arises when it becomes the norm. The team learns that quality is not a priority and stops demanding it of itself.

Turnover — knowledge of the system leaves with people. Every departure of an experienced developer represents an irreversible loss of context that is not captured in documentation. A new team member needs months to reach the productivity of their predecessor — and some context they will never acquire.

Missing ownership — no one is responsible for the long-term health of the system as a whole. Individual teams optimize their modules, but no one monitors whether the system as a whole is degrading.

Poor leadership and management. A technical lead or manager who does not understand technical debt, or who consciously ignores it, systematically harms the long-term health of the system. This manifests in refusing to allocate time for refactoring ("we don't have time to rewrite working code"), pressure to deliver features at any cost, an unwillingness to invest in training and tools, and making technology decisions on the basis of marketing rather than technical analysis. Especially destructive is micromanagement of technical decisions by incompetent leadership — developers lose autonomy and the motivation to propose quality solutions, because they know they will be overruled.

Demotivation and a toxic culture. A demotivated developer writes worse code — not out of ill will, but because quality requires energy and attention that a demotivated person does not have. Causes of demotivation directly relevant to DVR include: a sense of futility (the developer knows the system is degrading but has no mandate to change it), the absence of recognition for quality work (speed of delivery is rewarded, not maintainability), repeatedly rewriting work due to poor analysis or changing requirements, and a blame culture, where mistakes lead to punishment instead of systemic learning. A team in which people are afraid to admit a mistake cannot effectively conduct code reviews or retrospectives — and both are crucial for maintaining DVR.

Absence of feedback. If a team does not receive feedback about the quality of its code — whether from users, from operations, or from colleagues via code review — it lacks the information needed to improve. The system degrades without anyone noticing, until DVR reaches a critical value.

To quantify the slowdown, we propose the Development Velocity Ratio (DVR) metric — the ratio of effort for comparable functionality over time:

DVR(t) = E(t) / E(t₀)

where E(t) is the effort to add a feature of comparable complexity at time t, and E(t₀) is the effort to add the same feature at the start of the project. DVR = 1 means that the system maintains constant extensibility (the induction step holds). DVR > 1 means slowdown (the induction step fails). DVR < 1 would mean acceleration — rare, but possible, e.g., after a successful refactoring or the introduction of automation.

DVR is a continuous approximation of the discrete induction criterion from section 2.3. Whereas the formal model works with the index n (the order of a feature), DVR works with time t, which enables practical measurement on real projects, where features do not arrive in a deterministic order. DVR can be measured either by directly comparing analogous features of comparable complexity, or by normalizing against an estimated baseline effort in a clean system (see the case study in section 8).

DVR cannot be measured directly — we cannot implement the same feature twice in different periods. But we can approximate it in several ways.

Comparison of analogous features. We identify features of comparable inherent complexity implemented in different periods. Examples of pairs: adding a new user type (year 1) vs. adding a new role type (year 3); a new export format (year 1) vs. a new import format (year 3).

Normalization to story points. If the team uses agile estimation, we can track how many hours of actual work correspond to one story point over time. A rising hours/SP ratio indicates slowdown.

The ratio of productive to overhead code. For each change we measure how much code directly implements the new feature and how much addresses integration with the existing system, working around limitations, and fixing regressions. A rising share of overhead code indicates degradation.

Lead time for changes. The time from commit to production — one of the four metrics of the DORA framework (Forsgren et al., 2018). Its growth indicates slowdown. The remaining three DORA metrics — deployment frequency, change failure rate, and time to restore service — provide a complementary perspective.

On the basis of empirical observations and the professional literature (Lehman, 1980; Parnas, 1994) we can identify typical patterns. The exact mathematical function that DVR follows is not measurable in practice with sufficient granularity — what matters is the qualitative character of the growth.

Mild growth. DVR grows over time, but slowly. After several years, comparable functionality requires tens of percent more effort, not multiples. This is a natural accompanying phenomenon of a system's life — the system is viable in the long term with ordinary maintenance. This scenario is the best realistically achievable state.

Sustained significant growth. DVR grows noticeably year by year. Each year the situation is visibly worse than the previous one — comparable functionality requires multiples of the original effort. Typical of systems with accumulated technical debt and no repayment. The system requires a targeted intervention (refactoring, architectural changes), otherwise it becomes unmaintainable.

Accelerating growth. The slowdown accelerates itself — DVR not only grows significantly, but the rate of its growth increases. The system is heading toward the point at which it is cheaper to rewrite than to maintain. Typical of systems where all warning signals have been ignored for a long time.

Step growth. DVR is relatively stable, then jumps abruptly after a fundamental architectural change and stabilizes at a higher level. Typical causes of the jumps include a database migration (schema change, switch to a different engine), integration of an external system (payment gateway, ERP, a third party with its own API), a change of framework or runtime environment, a merger of teams or products (combining two systems into one), and a transition to new infrastructure (on-premise → cloud, monolith → microservices).

The key is to distinguish a healthy jump from an unhealthy one. A healthy jump means that DVR rises once (the team is getting used to the new architecture, resolving migration problems), but then stabilizes at a new level and does not grow further — the new architecture is viable. An unhealthy jump means that after the jump DVR continues to grow steadily — the architectural change did not bring the expected stabilization, it only added a layer of complexity. A typical example of an unhealthy jump is a move to microservices carried out without sufficient domain decomposition: the system inherits all the original problems and on top of that gains the complexity of distributed communication.

A practical recommendation: before every major architectural change, estimate its expected impact on DVR. If the team cannot credibly justify why DVR will stabilize after the initial jump, that is a warning signal.

Sawtooth pattern. DVR grows, then drops after a refactoring, then grows again. The team actively manages technical debt and periodically reduces it. This is the most realistic target state — no real system maintains DVR = 1 permanently, but a disciplined team can keep it within an acceptable range.

A healthy amplitude means that DVR oscillates within a narrow band (for example, 1.0–1.5) and the "teeth of the saw" are roughly equally high — each refactoring cycle returns DVR to a comparable level. An unhealthy amplitude manifests in two ways. First, growing teeth: each cycle reaches a higher maximum than the previous one (1.0–1.5 → 1.2–2.0 → 1.5–2.8). This signals that refactoring is treating symptoms but not causes — typically the code is being fixed, but not the architecture or processes. Second, growing minima: after a refactoring, DVR does not drop to its original level (the minimum shifts from 1.0 to 1.2, then to 1.5). This means that part of the technical debt is already "set in concrete" in the architecture and local refactoring cannot reach it.

The frequency of refactoring cycles depends on the rate of DVR growth between them. If DVR reaches an unacceptable level within 6 months, the team needs either shorter cycles (refactoring every 3–4 months), or a more systematic approach to prevention (better tests, reviews, documentation) that slows the rate of growth. In general, the smaller and more frequent the refactoring, the lower the risk — a large one-off rewrite is itself a source of architectural risk.

The key practical output is the identification of the breakpoint — the moment when the cost of continuing to extend the system exceeds the cost of a fundamental refactoring or rewrite.

Simply put: refactoring is economically justified when:

∫[t, t+T] DVR(τ) · Ē dτ > R + ∫[t, t+T] DVR_ref(τ) · Ē dτ

where the left-hand side represents the cumulative cost of development without refactoring over a horizon T, R is the one-off cost of refactoring, DVR_ref(τ) is the assumed curve after refactoring (a reset to a lower value), and Ē is the average effort for a "typical" feature.

This formula is deliberately simplified — it does not include the discount rate of money, the risk of an unsuccessful refactoring, opportunity costs, or the variability of Ē over time. In practice it serves as an indicative decision-making tool, not as a precise calculator.

The observations described in this article are not new. Meir Lehman originally formulated three laws of software evolution (1974), later expanded to eight (Lehman, Perry & Ramil, 1998). For our discussion the following are especially key:

Law I (Continuing Change): A system that is in use must be continually adapted, otherwise it becomes progressively less useful.

Law II (Increasing Complexity): As a system evolves, its complexity increases unless effort is expended to reduce it.

Law VI (Continuing Growth): The functional content of a system must continually grow in order to maintain user satisfaction.

Law VII (Declining Quality): The quality of a system will decline unless it is actively maintained and adapted to changes in its operating environment.

Lehman's laws describe symptoms. The induction criterion offers a diagnostic tool: a way to quantify and predict the slowdown.

The advent of AI tools for software development — IDE-integrated assistants (GitHub Copilot, Cursor, Windsurf) as well as general large language models (Claude, GPT) — fundamentally changes the context in which the induction criterion is applied. AI does not merely add new tools — it changes the very nature of the work, and with it the metrics by which we measure it.

AI tools dramatically reduce the time needed to produce code. What used to take a developer a day, an AI assistant generates in minutes. At first glance this should lower DVR. In reality the situation is more complex.

Positive effect on DVR. Faster implementation lowers E(n+1) for new code. AI assistants help with the "archaeological survey" of someone else's code — they can explain what the code does even without documentation. Test generation: AI lowers the barrier to creating test coverage, including retroactive coverage of legacy code. AI-assisted documentation enables the generation of docstrings, ADRs, and API documentation from existing code.

Negative effect on DVR. AI generates code faster than a developer can understand it. AI technical debt arises — code that works, but no one on the team understands why or how. The ease of generating code tempts one to skip analysis: why spend a week on analysis when AI writes a solution in an hour? But without analysis the solution is often poorly embedded in the context of the system. An illusion of productivity arises: metrics such as the number of commits or lines of code rise dramatically, while the actual value delivered to users need not grow proportionally. There is also a risk of homogenization of solutions: AI generates "typical" solutions that may not respect the specifics of a given system and its architecture.

Traditional productivity metrics (lines of code, number of commits, story points per sprint) were always problematic. In the AI era they become actively misleading.

Lines of code. AI generates code quickly and with excessive volume. A metric that was always dubious becomes meaningless. A team with AI can produce 10× more lines per sprint — and at the same time deliver less value, because the generated code requires more maintenance.

Story points per sprint (velocity). If AI enables faster implementation, velocity rises. But if the generated code increases S(n), future velocity falls. A short-term rise in velocity can mask a long-term rise in DVR.

Relevant metrics for the AI era. First, DVR remains valid — precisely because it measures the outcome, not the process. It does not matter whether the code was written by a human or by AI; what matters is whether adding comparable functionality requires comparable effort. Second, the ratio of generated to reviewed code — how much of the AI-generated code passes review unchanged? A high ratio may indicate insufficient review; a low ratio may indicate that AI is generating code unsuitable for the given context. Third, time-to-comprehension — how long does it take a new team member to understand a module? In the AI era this time paradoxically grows, because AI-generated code tends to be idiomatically correct but conceptually opaque. Fourth, defect escape rate — how many defects get through AI-assisted development into production? AI can generate code without syntax errors, but it catches logical errors and errors in domain logic less well.

Code review is one of the most effective preventive strategies against the growth of DVR. AI review is not meant to replace this strategy, but to extend and make it more efficient.

What AI review does well: detecting syntactic and stylistic problems (conventions, formatting, naming), identifying known anti-patterns and security vulnerabilities (SQL injection, XSS, buffer overflow), checking consistency with existing code (naming conventions, architectural patterns), 100% code coverage (AI review does not suffer from fatigue and does not skip "uninteresting" parts), and speed (an AI review runs in seconds, a human reviewer needs hours).

What AI review does not do (and where human review is irreplaceable): assessing whether a solution matches the intent of the requirement — AI lacks the context of the business domain. Furthermore, architectural decisions: whether a new component belongs in the right module, whether it violates aggregate boundaries. Detecting missing functionality: AI checks code that exists, not code that is missing. Assessing comprehensibility for a human: AI-generated code can be correct and yet unreadable for the team. And recognizing whether behavior is intentional or erroneous — see the undecidability problem in section 3.2.

The recommended workflow is two-stage. The developer (with AI assistance) writes the code. This is followed by AI review (automated, as part of the CI pipeline): syntax, security, anti-patterns, conventions, test coverage. Then a human review (a colleague): intent, architecture, domain correctness, comprehensibility, impact on the rest of the system. Thanks to the AI review, the human reviewer can focus on what AI cannot do — strategic decisions and domain context.

This two-stage model reduces the overall review time (AI catches trivialities that would otherwise take up the human reviewer's time) while also increasing quality (the human reviewer focuses on a higher level of abstraction).

AI offers a possibility that was previously unavailable: the retroactive generation of documentation from existing code. This directly addresses the problem of the undecidability of intentional vs. erroneous behavior. AI can analyze the code, the version history, and related comments and generate a hypothesis about the intent. This hypothesis is then validated by a human — a domain expert or the original developer. The result is documentation that did not previously exist and whose creation was too costly to be worthwhile.

This does not mean that AI replaces documentation. AI reduces the cost of the initial draft, which is then cheaper to revise than to write from scratch. By analogy with AI review: AI generates the basis, the human validates and adds context.

To summarize: AI changes both sides of the equation E(n+1) = f(C(n+1), S(n)). It reduces the influence of C(n+1) on E — thanks to AI assistance, the translation from a feature's complexity into implementation effort is more efficient. It can reduce S(n) — better documentation, more tests, automated review. But it can also increase S(n) — AI technical debt, code without understanding, the illusion of productivity.

The net effect depends on how the team uses AI tools. AI is a multiplier, not a solution. It multiplies the quality of a process that already exists. A disciplined team with AI will have a lower DVR. An undisciplined team with AI will have a higher DVR, because AI allows it to generate technical debt faster than ever before.

If the goal is to keep DVR close to 1 — that is, to preserve constant extensibility — what strategies make this possible? The following overview builds on the causes described in section 3 and the AI context from section 6.

Architectural decisions as an investment — assess every decision through the lens of "how will this affect DVR in 3 years?" Tests as a condition of delivery — no feature without automated tests, including regression tests; AI assistants dramatically reduce the cost of writing tests, which deprives the "we don't have time for tests" argument of its validity. Living documentation — documentation as part of the code (ADRs — Architecture Decision Records), not as a separate document that becomes obsolete; AI-assisted generation of documentation from code reduces maintenance costs. Two-stage code review — AI review in the CI pipeline (syntax, security, conventions) + human review (intent, architecture, domain), as described in section 6.3. Continuous Integration/Delivery — automated build, test, and deployment eliminates an entire category of overhead effort. AI literacy in the team — every team member must understand the limits of AI tools; AI-generated code requires the same or a higher degree of review than human-written code.

Regular measurement of DVR — a quarterly retrospective with an explicit comparison of the effort for comparable features. Tracking DORA metrics — lead time, deployment frequency, change failure rate, time to restore (Forsgren et al., 2018). Monitoring technical debt — tools such as SonarQube, AI-assisted analysis of the codebase, but also a qualitative assessment: "where is the system slowing us down?" Tracking AI-specific metrics — the ratio of generated to reviewed code, the defect escape rate of AI-generated code, the time-to-comprehension of new modules. Retrospectives focused on obstacles — not "what did we deliver," but "what got in our way and why?"

Cyclical refactoring — regularly allocate capacity (typically 15–20% of a sprint) to reducing technical debt; AI assistants can help with identifying refactoring candidates as well as with implementing it. The Strangler Fig pattern — the gradual replacement of problematic parts of the system with new ones, instead of a big rewrite. Retroactive documentation with AI — for legacy systems, use AI to generate documentation from code and version history, followed by human validation. Architectural spikes — before implementing a fundamental change, invest time in verifying that the chosen approach will not increase DVR.

The technical strategies from the preceding sections can fail if the organizational environment actively undermines them (see the causes in section 3.8). DVR is ultimately the result of people's decisions — and the quality of those decisions depends on the competencies, motivation, and conditions in which people work.

Training and competence development. Investment in education has a direct effect on DVR: a developer who understands the principles of clean architecture, SOLID, and testing produces code with a lower degree of technical debt. Training need not be limited to technical skills — an analyst's or developer's understanding of the business domain reduces the number of poor abstractions and erroneous decisions that feed into S(n). The key is that training should not be a one-off event, but an ongoing process: regular internal talks, knowledge sharing within the team, attendance at conferences, and time for self-study.

Motivation and ownership. A developer who feels ownership over the code has a natural motivation to maintain its quality — just as a homeowner invests in maintenance, while a tenant fixes only what is strictly necessary. Effective motivational tools include: assigning clear responsibility for modules or subsystems (code ownership), recognition and appreciation of quality work (not just fast delivery, but also maintainability, well-written tests, quality documentation), autonomy in technical decisions (the team chooses the solution, leadership defines the goals), and visibility of the impact of the work (the developer sees how their code serves users).

Psychological safety. A team in which people are not afraid to admit a mistake, report a problem, or propose an unpopular refactoring has a significantly lower DVR. Psychological safety (Edmondson, 1999), confirmed as a key factor of effectiveness in technical teams as well (Google Project Aristotle, 2015), is a prerequisite for effective code review, honest retrospectives, and the timely identification of technical debt. Without it, problems pile up because no one wants to be the bearer of bad news.

Quality of leadership. A technical lead directly influences DVR through their decisions about time allocation, task prioritization, and technology choices. Effective leadership in the context of DVR means: understanding refactoring as an investment (not as a waste of time), shielding the team from unrealistic deadlines (or at least transparently communicating the consequences of compromises), creating space for training and experimentation, and deciding on technologies on the basis of technical analysis, not marketing.

A transition to new technologies can lower DVR (better tools, a more modern framework, more powerful infrastructure), but it can also raise it (see step growth in section 4.3). The key is to distinguish a conscious investment from a fad.

A conscious investment means that the team identifies a concrete problem that the new technology solves (e.g., "our CI pipeline takes 45 minutes; switching to incremental builds will shorten it to 5 minutes"), estimates the impact on DVR, and plans the migration as a managed process. A fad means that the team adopts a new technology because "everyone is using it" or because a conference keynote recommended it — without analyzing whether it solves a real problem of the given system.

In general, investments in automation (CI/CD, automated tests, infrastructure-as-code) have the most reliable positive effect on DVR, because they eliminate entire categories of overhead effort. Investments in new languages or frameworks are riskier — they bring a one-off jump in DVR (the learning curve) with an uncertain long-term benefit.

For illustration, consider the development of an e-commerce platform over 5 years:

Year / Feature added / Inherent complexity / Baseline effort / Actual effort / DVR

1 / Product catalog / Medium / 3 weeks / 3 weeks / 1.0

1 / Cart and orders / Medium / 3 weeks / 3 weeks / 1.0

2 / Payment gateway / Medium / 3 weeks / 4 weeks / 1.3

2 / User reviews / Low / 1.5 weeks / 3 weeks / 2.0

3 / Discount system / Medium / 3 weeks / 6 weeks / 2.0

3 / Multi-warehouse / Medium / 3 weeks / 8 weeks / 2.7

4 / New delivery type / Low / 1.5 weeks / 5 weeks / 3.3

5 / Loyalty program / Medium / 3 weeks / 12 weeks / 4.0

The "baseline effort" column shows the estimated effort that the given feature would require in a clean system (year 1). For medium complexity the baseline is 3 weeks, for low complexity 1.5 weeks. DVR is the ratio of actual effort to baseline.

DVR in year 5 reaches a value of 4 — comparable functionality requires four times the original effort. The curve exhibits accelerating growth: the rate of slowdown is itself increasing. Without intervention, one can expect DVR to keep accelerating and, within the next 2–4 years, to reach values at which the system becomes practically unextensible.

If a refactoring takes 3 months and resets DVR to 1.5, it is economically justified at any point after year 4.

In previous work (The Relational Nature of Reality, 2025), the author analyzed the properties of relational models in which all relationships are of type 1:N and apparent M:N relationships are decomposed into explicit junction entities. Such a model exhibits the properties of consistency and extensibility of the data layer.

The induction criterion represents a generalization of this principle: extensibility is not a property of the data model alone, but of the entire information system, and it depends on the quality of all of its aspects — analysis, architecture, code, tests, documentation, tools, and processes.

A correctly designed relational model with exclusively 1:N relationships is a necessary condition for the extensibility of the data layer, but not a sufficient condition for the extensibility of the entire system. Even a system with a perfect data model can slow down if it suffers from the other problems described in section 3.

The principle of mathematical induction provides an elegant and practically usable framework for assessing the health of information systems.

Definition. A system is unboundedly extensible if the effort to add a feature depends primarily on the complexity of that feature, not on the state of the system.

Diagnosis. The development-slowdown curve (rising DVR) is a measurable symptom of a failing induction step.

Causes. The failure of the induction step has many causes — technical debt, missing tests, poor documentation (including the principled undecidability of intentional vs. erroneous behavior), unsuitable architecture, poor tools, insufficient analytical and programming work, but also organizational factors: poor leadership, demotivation, a toxic culture, and the absence of feedback.

Prediction. From the shape of the DVR curve one can extrapolate future costs and identify the point at which refactoring becomes economically necessary.

Prevention. Maintaining a constant DVR requires a systematic investment in quality across all aspects of development — and not only technical ones. Training, motivation, psychological safety within the team, and the quality of leadership have an effect on DVR comparable to that of code and test quality. Investments in new technologies lower DVR only when they are a conscious response to a concrete problem, not a fad.

AI as a multiplier. AI tools change the metrics and processes of development, but they do not change the validity of the induction criterion. DVR remains relevant precisely because it measures the outcome, not the process. AI is a multiplier of existing quality — it helps a disciplined team keep DVR low, and allows an undisciplined one to generate technical debt faster than ever before. The two-stage review model (AI + human) and AI-assisted documentation are key strategies for the AI era.

Development slowdown is not inevitable. It is a consequence of violating the induction step — and as such it is measurable, predictable, and solvable.

Methodological note

The concept, structure, and editorial line of the article are the work of the author, who prepared the content outline, established the key theses, and directed the entire creative process. Generative AI (Claude, Anthropic) was used as a technical tool for research, fact-checking, and elaborating the author's draft.

The author edited the outputs throughout, verified the key findings, and approved the final wording. No part of the text was published without human review. All factual data were verified against the publicly available sources cited in the text.

The procedure complies with the requirements of Article 50 of EU Regulation 2024/1689 (AI Act) on the transparency of AI-generated content. #poweredByAI