Code Quality Engineering

Cyclomatic complexity (McCabe, 1976) counts the independent paths through code by counting decision points (if, while, for, case, &&, ||) and adding one. A function with no branches has complexity 1; each branch adds to it. High cyclomatic complexity means more paths to test and reason about, correlating with defect rates and maintenance difficulty. Many teams flag functions above ~10 for refactoring. It directly informs test coverage: you need at least that many test cases to exercise every independent path.

Cognitive complexity (introduced by SonarSource) was designed to better reflect human readability rather than testability. A flat switch statement has high cyclomatic complexity but is easy to read, so cognitive complexity scores it low. Conversely, deeply nested conditionals are hard to follow, so cognitive complexity penalizes nesting heavily. It also penalizes flow-breaking jumps (break, continue, goto). The two metrics are complementary: cyclomatic tells you how many tests you need; cognitive tells you how painful the code is to maintain.

The Single Responsibility Principle states that a module should have one reason to change — it should serve a single actor or concern. If a class handles both report formatting and database persistence, then a change in reporting requirements and a change in storage both force edits to the same class, increasing the risk of breakage and merge conflicts. Splitting responsibilities yields smaller, more cohesive, independently testable units. SOLID is Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion.

The classic design goal is low coupling, high cohesion. Coupling is the degree to which one module depends on the internals of another — tightly coupled modules break each other when changed, so you want loose coupling (depend on stable interfaces, not implementations). Cohesion is how focused and related the elements within a module are — a highly cohesive module does one well-defined thing. A well-designed system has modules that are internally cohesive but externally loosely coupled, making them easier to change, test, and reuse independently.

The technical debt metaphor (Ward Cunningham) frames shortcuts as borrowing: you ship faster now but owe later. The interest is the recurring extra cost the debt imposes on every subsequent change — slower features, more bugs, harder onboarding. Unlike principal (the cost to fix it once), interest compounds the longer the debt remains. This framing helps teams prioritize: debt in frequently-changed, high-traffic code has high interest and should be paid down first; debt in stable, rarely-touched code may be fine to leave. A debt register makes this trade-off explicit.