Vanity Engineering Review

Vanity Engineering Review

A diagnostic skill that identifies code, architecture, and technical decisions built to impress rather than to ship. Vanity engineering is entropy disguised as craftsmanship — it increases complexity without proportional capability gain, and it compounds maintenance cost while delivering zero additional user value.

Core Premise

The only legitimate purpose of engineering is to solve a problem someone actually has.

Everything else — elegant abstractions nobody traverses, microservices that serve one endpoint, custom frameworks that replicate existing tools, type systems more complex than the domain they model — is vanity. It may feel productive. It is not.

This skill does not oppose quality, rigour, or good engineering. It opposes engineering that exists to satisfy the builder rather than the user.

When to Apply This Skill

Apply this review to any of:

• Codebase audits (full repo or specific modules)
• Pull request reviews
• Architecture proposals or RFCs
• Technology selection decisions
• Refactoring plans
• "Should we rebuild this?" discussions
• Post-mortems where complexity contributed to failure

The Review Process

Phase 1: Establish the Requirement Anchor

Before examining any code, establish what the system actually needs to do. Without this anchor, you cannot distinguish necessary complexity from vanity complexity.

Ask (or determine from context):

1. Who uses this? (End users, internal team, API consumers, nobody yet)
2. What must it do? (Core user stories / jobs-to-be-done — max 5)
3. What scale does it actually operate at? (Not projected. Actual.)
4. What are the real constraints? (Regulatory, latency SLAs, integration requirements)
5. What is the team size maintaining this? (Solo dev? 3-person startup? 50-person org?)

If the user cannot answer these, that is itself a vanity signal — building without defined requirements.

Phase 2: Detection Scan

Scan the codebase or architecture against the detection patterns in references/detection-patterns.md. Read that file before proceeding.

Score each finding using the Vanity Severity scale:

• V0 — Cosmetic: Unnecessary but harmless. Adds no maintenance burden. Note and move on.
• V1 — Drag: Adds ongoing cognitive or maintenance cost without user value. Flag for simplification.
• V2 — Structural: Shapes architecture around vanity rather than requirements. Flag for redesign.
• V3 — Compounding: Actively forces other code to be more complex to accommodate it. Flag as urgent — this metastasizes.

Phase 3: The Vanity Score

Produce a structured assessment:

## Vanity Engineering Assessment

### Summary
[One paragraph: What this codebase does vs what it is engineered to do.
The gap between these two is the vanity surface area.]

### Requirement-to-Complexity Ratio (RCR)
[Scale 1-10. 1 = minimal viable solution. 10 = PhD thesis disguised as a CRUD app.
Most production systems should score 2-4.]

### Top Findings (max 7)
For each finding:
- What: The specific pattern detected
- Where: File/module/component
- Severity: V0-V3
- Why it is vanity: How it fails the "does a user need this?" test
- What it should be instead: The simpler alternative
- Kill cost: Effort to remove or simplify (hours/days)

### Vanity Debt Estimate
[Total accumulated complexity cost from vanity engineering.
Express as: person-hours of maintenance per month attributable to
vanity patterns rather than actual requirements.]

### The Hard Question
[One direct, uncomfortable question the team needs to answer honestly.
Example: "If you deleted the entire plugin system and hardcoded the
three integrations you actually use, what would you lose?"]

Phase 4: Kill Criteria Generation

For every system or feature reviewed, generate a kill criteria framework. This is the most important deliverable — it prevents vanity engineering from recurring.

Read references/kill-criteria-template.md for the full template, then generate a project-specific version.

Kill Criteria Philosophy

Kill criteria exist because humans are bad at stopping things. We are wired to continue what we started (sunk cost), to add rather than remove (addition bias), and to interpret complexity as value (effort justification). Kill criteria counteract all three by making the stop decision automatic, pre-committed, and ego-independent.

Tier 1 — Hard Kill (Automatic, Non-Negotiable)

These trigger immediate shutdown with no debate. They exist for situations where continuing causes escalating damage. No human approval needed — if the condition is met, the thing dies.

Examples:

• Security breach traced to the component
• Production incident caused by the component with severity >= P1
• Cost exceeds budget cap for 3 consecutive days
• The component has zero usage for 30 days (no API calls, no page views, nothing)
• The sole maintainer leaves and no one volunteers to own it within 2 weeks

Tier 2 — Review Trigger (Automatic Flag, Human Decision)

These do not kill automatically but force a mandatory review with a default-to-kill bias. The burden of proof is on continuing, not on stopping.

Examples:

• Success metric below threshold for 14 consecutive days
• Maintenance cost exceeds value delivered (eng-hours/month vs user impact)
• Three consecutive sprints with unplanned work on the component
• Any dependency it introduced has a CVE with CVSS >= 7.0
• Team velocity measurably decreased since introduction