Featured R&D
CodeFriction
Software Maintainability & Comprehension Risk Analyzer
CodeFriction analyzes characteristics of software that create friction in understanding, reasoning about, and safely modifying it.
Overview
CodeFriction analyzes characteristics of software that create friction in understanding, reasoning about, and safely modifying it.
Software can be correct, operational, and conventionally measurable while still being unusually difficult to understand well enough to change with confidence.
CodeFriction investigates that gap.
Rather than attempting to measure developers, the research focuses on the software itself: the structural and behavioral characteristics that may increase the reasoning required to understand a system before modifying it safely.
The Problem
Software that works can still be difficult to understand safely.
Software-engineering teams routinely inherit, maintain, review, and modify systems they did not originally create.
Before changing that software, an engineer must develop enough understanding to reason about questions such as:
- What behavior depends on this code?
- What other parts of the system are affected?
- What assumptions are embedded in the implementation?
- What could change unintentionally?
- How much of the surrounding system must be understood before this modification can be made confidently?
Traditional software measurements can provide useful evidence about properties such as complexity, size, coupling, or dependencies. Those measurements do not necessarily answer the more practical question:
How difficult is this software to understand well enough to modify it safely?
That distinction motivates CodeFriction.
The research is not based on the premise that existing software metrics are wrong. It asks whether those measurements—and potentially other observable characteristics—can be placed into a broader analytical framework focused specifically on comprehension friction.
The engineering significance lies at the end of that chain. Difficulty understanding software matters because uncertainty about behavior, dependencies, and consequences can make modification more difficult to reason about safely.
Research Question
How difficult is this software for an engineer to understand well enough to modify it safely?
At the current stage, that broad question is also the active research problem.
Before an analyzer can answer it, the research must determine whether the question can be transformed into an evidence-based analytical model at all.
That requires answering more fundamental questions:
- Which observable characteristics of software contribute meaningfully to comprehension friction?
- Which characteristics matter only in combination with others?
- How much context is required before an observation becomes meaningful?
- At what scope should characteristics be evaluated?
- Can useful indicators remain interpretable?
- How can those indicators be evaluated without turning developer cognition into the object being measured?
The immediate R&D challenge is therefore not building a score.
It is making the problem sufficiently precise to investigate.
The Approach
Analyze the software, not the developer.
CodeFriction establishes a deliberate analytical boundary around the object of study.
The research is concerned with characteristics of software that may create resistance to understanding and reasoning.
It is not intended to measure:
- developer intelligence;
- individual cognitive ability;
- developer productivity;
- developer speed; or
- engineering competence.
The distinction matters both technically and methodologically.
An engineer's experience, familiarity with a codebase, domain knowledge, and individual reasoning strategies can all influence how difficult a particular change feels. Building an analyzer around those individual characteristics would create a fundamentally different research problem.
CodeFriction instead asks what can be observed in the artifact itself.
The intended output is evidence that supports engineering judgment—not a machine-generated declaration about whether an engineer can or cannot understand a piece of software.
Research Framework
At Research maturity, the framework itself is the evidence-bearing work.
CodeFriction does not yet have a validated comprehension-risk model, production analyzer, or established scoring system.
The current work is the structured research framework needed to determine whether such an analytical system can be built responsibly.
The framework begins with observable characteristics of software and asks how those characteristics might contribute to demands placed on understanding.
Potential areas of investigation include characteristics associated with:
- structural relationships;
- dependencies;
- control complexity;
- data relationships;
- indirection;
- coupling; and
- interactions among multiple characteristics.
These are candidate analytical dimensions, not a finalized CodeFriction taxonomy.
That distinction is important.
The research must establish which dimensions actually carry useful information, which are redundant, which require contextual interpretation, and which may prove irrelevant to comprehension friction.
The framework therefore remains intentionally open to revision.
From characteristics to evidence
A useful analytical model would need to move through several levels of reasoning:
Each transition represents a research problem.
Observability does not automatically imply relevance.
Relevance does not automatically imply that a characteristic can be interpreted independently.
And an indicator does not become useful merely because it can be reduced to a number.
Technical Deep Dive
Metrics Are Evidence, Not Conclusions
A measurable characteristic is not automatically a measure of comprehension friction.
This distinction is central to CodeFriction.
Software engineering already provides many ways to quantify aspects of source code and system structure. A metric might describe complexity, coupling, dependency count, size, nesting, or some other observable property.
Those measurements can be useful inputs.
But consider the inference:
High complexity
↓
High comprehension friction
That relationship cannot simply be assumed.
A characteristic may be significant in one context and relatively unimportant in another. Two individually modest characteristics may interact in a way that creates substantial reasoning difficulty. A conventionally high metric may also occur in code whose structure makes its behavior comparatively easy to understand.
The CodeFriction research target is therefore more contextual:
The important question is not merely:
Can this characteristic be measured?
It is:
Does this characteristic, alone or in combination with others, provide interpretable evidence that understanding this software may be unusually difficult?
That changes the role of conventional metrics.
They become possible evidence sources within a larger analytical model rather than conclusions in themselves.
Current Research Findings
The current stage of CodeFriction has produced conceptual boundaries and research requirements rather than experimentally validated predictive findings.
Those boundaries are important because they define what the project should—and should not—attempt to claim.
Software, Not Developers
The software artifact is the object of analysis.
CodeFriction investigates observable characteristics of software that may resist comprehension.
It does not attempt to quantify the intelligence, ability, productivity, or competence of the engineer examining that software.
This boundary keeps the research focused on properties that can potentially be inspected, reproduced, and discussed independently of individual developer assessment.
Safe Modification Is the Engineering Target
The concern is not readability in the abstract. It is understanding sufficient for safe modification.
CodeFriction is motivated by a practical engineering activity: changing existing software.
The relevant question is not whether code appears elegant, concise, or aesthetically readable.
It is whether characteristics of the software make it harder to build enough understanding to reason confidently about the consequences of a change.
This gives comprehension friction an engineering consequence rather than treating readability as an end in itself.
Metrics Are Inputs, Not Conclusions
Complexity, coupling, size, or dependency measurements may contribute evidence without individually defining comprehension risk.
No conventional software metric should automatically be renamed or treated as a CodeFriction score.
The research must determine what relationship—if any—exists between candidate characteristics and the analytical target.
That relationship may depend on context and interactions with other characteristics.
Context Matters
A software characteristic may become meaningful because of its relationships, not merely because it exists.
A dependency count, branch structure, layer of indirection, or data relationship may tell only part of the story.
The research must investigate whether combinations and structural relationships explain comprehension friction more effectively than isolated measurements.
This is one reason a simple weighted sum of conventional metrics should not be assumed to be the eventual solution.
Interpretability Matters
An indicator should help explain why software may resist understanding.
A single opaque score could tell an engineer that something is supposedly difficult without providing useful evidence about what makes it difficult.
A more useful analytical result would expose contributing characteristics and relationships.
Conceptually:
Interpretability is therefore not merely a presentation concern. It is a research requirement.
What the Research Does Not Yet Establish
The framework defines the investigation. It does not yet validate the answer.
At the current maturity, CodeFriction does not establish:
- a validated set of comprehension-friction indicators;
- a validated scoring model;
- predictive accuracy;
- universal relationships between individual software metrics and comprehension difficulty;
- a quantitative measure of developer cognition;
- a measure of developer productivity;
- an automatic determination that software is safe or unsafe to modify; or
- a production-ready analyzer.
These are evidence boundaries, not omissions to disguise.
Making them explicit is part of the R&D process: the next stage should be driven by questions the current work has made testable rather than by capabilities the project is presumed to have.
Next Investigation
The next step is to move from a structured research question toward testable indicators.
The immediate objective is not to implement a complete analyzer.
It is to determine whether candidate characteristics can be transformed into meaningful, interpretable evidence and evaluated experimentally.
A likely progression is:
The next investigation needs to address questions including:
- Which observable software characteristics meaningfully contribute to comprehension friction?
- Which characteristics are useful only in combination?
- At what scope should an indicator be evaluated?
- How does local code context affect interpretation?
- How does broader architectural context affect it?
- Can indicators remain explainable?
- How should conflicting indicators be represented?
- What constitutes useful engineering assessment for experimental comparison?
- How can evaluation avoid making individual developer ability the measured variable?
- What evidence would justify progression from Research to Experiment?
A successful next stage does not require proving the entire CodeFriction concept.
It requires enough evidence to determine whether the proposed analytical direction deserves deeper experimental development.
Where This Applies
The broader problem is knowing where understanding itself may become an engineering risk.
If the research produces useful indicators, CodeFriction could inform engineering activities such as:
- maintainability assessment;
- legacy-system modernization;
- code-review prioritization;
- refactoring analysis;
- technical-debt investigation;
- architecture comprehension;
- onboarding into unfamiliar codebases; and
- identifying areas that warrant deeper analysis before modification.
At Research maturity, these are application areas for the underlying idea—not claims of capabilities already delivered.
The transferable engineering concept is broader:
Use observable properties of software to identify where comprehension itself may warrant additional engineering attention.
That concept could be useful anywhere engineers must decide how much investigation is appropriate before modifying unfamiliar or structurally difficult software.
Project Status
The problem has been bounded. The analytical model is still being established.
| Maturity: | Research |
|---|---|
| Domain: | Software maintainability and comprehension risk |
| Object of analysis: | Software characteristics and relationships |
| Current focus: | Identifying and structuring characteristics that may contribute to comprehension friction |
| Evidence-bearing work: | Research framework, analytical boundaries, and candidate dimensions for investigation |
| Current objective: | Establish an interpretable analytical framework suitable for experimental evaluation |
| Explicit boundary: | CodeFriction does not measure individual developer cognition, intelligence, productivity, or capability |
| Next maturity question: | Can candidate indicators be evaluated experimentally against representative software and engineering assessment strongly enough to justify progression to Experiment? |
Bring Us a Difficult Problem
Some engineering problems arrive before the correct metric, algorithm, or architecture is obvious.
The first useful result may not be software.
It may be a better question.
CodeFriction demonstrates an R&D process that begins by separating the observable artifact from assumptions about the people interacting with it, defining what existing measurements can and cannot establish, and turning an intuitive engineering concern into something that can eventually be tested.
That is a legitimate starting point for Applied Software R&D.
Have a technical problem where the right analytical approach isn't obvious?