- Description
- Échiquier en bois vide, dont les cases forment une grille régulière.
- Source
- Paul Lloyd · original page
- Licence
- CC0 Public domain
Maturity Matrix — Software Development (code DL)
This matrix measures code engineering and its delivery: from architecture to testing, from the integration chain to operations, from security to the developer's daily…
In brief
This matrix measures code engineering and delivery: from architecture to testing, from the integration chain to operations, from security to the developer's daily experience. For each theme, five levels; each level carries a promise (an observable outcome) and verifiable milestones. It differs from the IT project management matrix (steering, governance, people), the data project matrix (data as an asset), and the BI development matrix (the BI product).
Level: 🟢→🔴 · 12 themes · matrix code DL
Domain promise#
A high-level team on this matrix changes its software quickly, frequently, and without fear, and knows within minutes whether a change is safe, within hours whether it is in production, and within days how to undo it. It proves its quality metrics rather than claiming them. Level 5 is, by principle, very difficult to fully reach: it shows the horizon to encourage progress, even if milestones are only partially achieved.
The numeric benchmarks on the pages (lead times, rates, frequencies) are expert orders of magnitude, not normative thresholds; reference research (Accelerate, DORA reports) supports the correlation between delivery practices and performance, but the exact values of performance classes evolve: check the source (as of 2026-10).
Audience and use#
- Development team: quarterly self-assessment (one hour per theme), then selection of 2 or 3 milestones to target. See self-assessment.
- Technical or team lead: read profiles, dependencies between themes, and signs of false positives.
- Trainer: each theme serves as discussion support (“what does the next level look like?”).
- Recommended use: compare the team to itself over time. Avoid comparing teams to each other (different contexts) and linking the score to individual evaluation (Goodhart's law).
Scope#
In scope: everything related to building, delivering, and operating code (application code, SQL, scripts, deployable models). The illustrative thread is a SQL Server datamart fed by a field application, with multilingual Power BI reports, versioned in TFVC and delivered as installation kits.
Out of scope (covered elsewhere, with links):
| Topic | Where to find it |
|---|---|
| Steering, governance, budget, stakeholders | IT Project Management Matrix |
| Data quality, governance, and compliance, GDPR | Data Project Management Matrix |
| Semantic model, DAX, RLS, report accessibility | BI Development Matrix |
| Tool selection, version control system comparisons | 02_Outils |
| Methods (Scrum, Kanban, V-model cycles…) | 01_Conduite-de-projet |
The twelve themes#
| # | Code | Theme | In one sentence |
|---|---|---|---|
| 01 | ARC | Architecture and Design | Change at bounded cost: clear boundaries, tracked decisions, verified rules. |
| 02 | COD | Code Quality | Defects caught before merge, useful reviews, quality of new code guaranteed. |
| 03 | TST | Testing | A fast, reliable, truly detecting test suite (coverage, mutation, contracts). |
| 04 | GIT | Version Control and Branching | Complete traceability, small batches, fixes backported to all versions. |
| 05 | CIC | Continuous Integration and Delivery | One reproducible artifact, promoted as-is, from commit to production. |
| 06 | DEP | Deployment and Operations | Routine, reversible, no-downtime release, idempotent migrations. |
| 07 | SEC | Security | Secrets, dependencies, threats, SBOM, and provenance under control. |
| 08 | OBS | Observability and Reliability | Detect before users, diagnose quickly, steer by SLO. |
| 09 | DTT | Technical Debt and Maintainability | Debt is a quantified, arbitrated, and repaid portfolio. |
| 10 | DOC | Documentation and Knowledge Transfer | High truck factor, living documentation adjacent to code. |
| 11 | PRF | Performance and Scalability | Tested performance budgets, planned growth, tracked cost. |
| 12 | DXF | Developer Experience and Flow | Short feedback loops, limited WIP, blockers removed. |
Milestone identifiers follow the pattern DL-<CODE>-<level>.<n> (example: DL-TST-3.2 = DL matrix, testing theme, level 3, milestone 2).
Theme × level summary#
| Theme | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| ARC | Emerging | Described | Bounded | Governed by verified rules | Components replaceable without downtime |
| COD | Individual | Conventions + review | Tool-verified | Controlled: clean new code | Fearless refactoring |
| TST | Manual | Replayable critical paths | Reliable suite < 15 min | Calibrated (mutation, contracts) | Escaped defects → tests |
| GIT | Copies | Versioned history | Linked, fixes ≤ 1 day | Small batches, branches < 2 days | Trunk always releasable |
| CIC | Handcrafted | Scripted | Automatic pipeline < 15 min | One artifact promoted everywhere | Change → production < 1 day |
| DEP | Heroic | Procedural | Repeatable, tested rollback | No downtime, progressive | Autonomous, auto rollback |
| SEC | Trusting | Hygiene (secrets, permissions) | Detected in CI | Anticipated (threats, SBOM) | Proven provenance |
| OBS | Blind | Clear outages seen | Diagnosed (correlated logs) | Steered by SLO | Resilient, outage drills |
| DTT | Endured | Recognized | Arbitrated (interest cost) | Measured (change lead time) | Sustainable, capped |
| DOC | Oral | Written | Maintained, owner and date | Living, generated, reviewed | Truck factor ≥ 3 |
| PRF | Endured | Measured | Budgeted, regression tested | Planned (×3, capacity) | Elastic, tracked unit cost |
| DXF | Endured | Equipped | Fast (short loops) | Smooth (WIP, self-service) | Blockers resolved continuously |
Rating rule#
Each milestone has progress 0 / 0.5 / 1. A level N is achieved if the average progress of all milestones from levels 1 to N is ≥ 0.8 and no milestone is at 0. Theme score = N_achieved + average progress of milestones at level N_achieved+1 × 0.99 (e.g., 2.4). Matrix score = weighted average of themes (default weight 1, modifiable). A whole score of 5.0 is exceptional and may never be reached: that is not a failure.
“Testing” theme: levels 1 and 2 at 100%, level 3 at an average of 0.9 (no milestone at 0). The average of levels 1-3 is > 0.8: level 3 achieved. Milestones at level 4 average 0.4: score = 3 + 0.4 × 0.99 ≈ 3.4.
A milestone at 0 blocks achievement of the level even if the average is excellent. This is intentional: a single missing link (rollback never tested, for example) invalidates the promise.
Proof convention: a milestone is at 1 only if the indicated verifiable evidence has actually been observed (not declared). See also the rating for this section.
How to read scores#
| Score | What it says | What you can expect |
|---|---|---|
| 0 – 1 | Individual practices, little sharing. | Results depend on individuals; rare and stressful releases. |
| 1 – 2 | Practices described and repeatable manually. | Works as long as key people are present; little automation. |
| 2 – 3 | Tooled practices on main paths. | Regular releases; common defects seen before production. |
| 3 – 4 | Measured and managed practices. | Team improves capacity through data; incidents contained. |
| 4 – 5 | Proven and predictive practices. | High, stable change capacity; regular drills. |
These ranges describe, without moral judgment, a situation: a stable maintenance product at 2.5 may be perfectly appropriate; a fast-evolving product at 2.5 runs into its limits.
Where to start and dependencies#
Entry points (high return, moderate effort): 04 Version Control and Branching (everything depends on traceability), 03 Testing (confidence drives speed), 07 Security level 2 (secrets and permissions, low cost and high avoided risk).
Main dependencies (A → B: progressing on A strongly facilitates B):
04 GIT ─► 05 CIC ─► 06 DEP ─► 08 OBS
03 TST ─► 05 CIC │
02 COD ─► 03 TST ▼
01 ARC ─► 03 TST 11 PRF, 07 SEC
01 ARC ─► 09 DTT ◄─ 02 COD
10 DOC ◄► 12 DXF (cross-cutting: affect all others)
- Testing before continuous delivery: without a reliable suite, automating delivery automates risk.
- Version control before continuous integration: without small batches and traceability, the chain remains handcrafted.
- Observability before progressive deployment: you cannot deploy progressively what you cannot observe.
- Security: level 3 assumes the CI chain; level 5 assumes reproducible builds (05).
Typical organization profiles#
Plausible illustrative scores (simplified, non-normative contexts):
| Profile | Description | ARC | COD | TST | GIT | CIC | DEP | SEC | OBS | DTT | DOC | PRF | DXF | Average |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A. Solo craftsperson | One expert, one product, rare releases | 1,3 | 1,0 | 0,8 | 2,0 | 1,0 | 1,2 | 1,0 | 0,6 | 0,8 | 0,5 | 1,5 | 1,5 | ≈ 1,1 |
| B. Product team of 5-8 (datamart + reports) | TFVC, kits, partial tests | 2,3 | 2,2 | 2,0 | 2,8 | 2,3 | 2,4 | 1,8 | 1,6 | 1,8 | 2,0 | 2,3 | 2,0 | ≈ 2,1 |
| C. Mature product team | Pipeline, DORA metrics, SLO | 3,5 | 3,4 | 3,6 | 3,9 | 3,8 | 3,5 | 3,0 | 3,3 | 3,0 | 3,2 | 3,2 | 3,3 | ≈ 3,4 |
| D. Platform organization (elite) | Automatic rollback, signed provenance | 4,2 | 4,0 | 4,3 | 4,4 | 4,6 | 4,3 | 4,0 | 4,2 | 3,8 | 3,8 | 4,0 | 4,1 | ≈ 4,1 |
Look at the sawtooth profile rather than the average: a team at 4 in CI/CD and 1.5 in security has higher risk than a uniform team at 2.5. The average hides the weak link; milestones at 0 reveal it.
Limitations of the matrix#
- Context: a throwaway prototype does not need level 4 architecture; target the level that matches the cost of failure and product lifespan.
- Measurement ≠ value: a team can have an excellent score and deliver the wrong product. The matrix says nothing about fit to need (Scoping and Vision).
- Goodhart: any indicator turned into a target gets gamed. Each theme lists typical gaming patterns; audit them by sampling.
- Subjectivity: 0/0.5/1 progress is judged on evidence; have it validated by a third party (peer from another team).
- Platforms and technologies: milestones are phrased as outcomes; implementation varies (Git or TFVC, hosted or on-prem pipeline). Means cited on the pages are optional.
- Volatility: some benchmarks (DORA classes, SBOM formats, SLSA levels) evolve; check at the source before freezing them in policy (as of 2026-10).
See also#
- Other matrices: IT Project Management · Data Project Management · BI Development · self-assessment · matrix portal.
- Practice: CI/CD · CI/CD for Data: Databases, Datamarts, Pipelines, and Reports · Version Control Systems Overview · Git In Depth · TFVC In Depth · Branching Strategies · Azure DevOps / TFS · Project Metrics and Reporting · Project Management Pitfalls and Best Practices (Cross-Cutting Summary).
- Power BI reporting: Cross-Cutting Power BI Best Practices.
- Glossary · Rating · Reading Paths.
✻ Written by Claude Sonnet 5.5
