1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
//! # Performance Metrics and Outcome Proxies
//!
//! **Performance**, the P in SPACE (chapter 3.1), is the dimension most
//! often confused with activity: it asks whether work actually produced a
//! good outcome, not how much motion occurred. A team can be highly active
//! and low performing, shipping constant small changes that never move an
//! outcome, and the reverse is equally possible. Outcome is also rarely
//! attributable to a single person or team — it emerges from collaboration,
//! from decisions made months earlier, from market conditions no engineer
//! controls — so SPACE researchers were explicit that performance should be
//! measured at the system or team level using multiple, converging
//! signals, never reduced to a single number or attributed to an
//! individual.
//!
//! ## Formula
//!
//! ```text
//! Converging signal count = count of independent signals indicating
//! positive performance (change failure
//! rate, defect-escape rate, adoption,
//! qualitative peer assessment, ...)
//! Sufficient converging evidence = converging signal count >= 2
//! (no single signal is reliable alone)
//! ```
//!
//! ## Why it matters
//!
//! No individual performance proxy is reliable enough to stand alone: a
//! single metric can look good while quality quietly degrades, or look bad
//! for reasons entirely outside a team's control. Requiring several
//! independent signals to agree before drawing a conclusion is what
//! resists both accidental misreading and deliberate gaming of any one
//! proxy — the same discipline chapter 5.3 applies to business-outcome
//! attribution, applied here to the SPACE performance dimension
//! specifically.
//!
//! ## Example
//!
//! ```rust
//! use software_engineering::performance_metrics::{
//! converging_signal_count, has_sufficient_converging_evidence,
//! };
//!
//! // A single positive signal (adoption is up) is not enough on its own.
//! let adoption_only = [true, false, false];
//! assert_eq!(converging_signal_count(&adoption_only), 1);
//! assert!(!has_sufficient_converging_evidence(&adoption_only));
//!
//! // Change failure rate down, defect-escape rate down, and adoption up
//! // all agree: two or more converging signals are trustworthy together.
//! let converging = [true, true, false, true];
//! assert_eq!(converging_signal_count(&converging), 3);
//! assert!(has_sufficient_converging_evidence(&converging));
//! ```
//!
//! ## Pitfalls
//!
//! - **Reducing performance to a single number** — no individual proxy
//! (velocity, adoption, a single quality metric) is reliable enough to
//! stand alone.
//! - **Attributing an outcome to one individual** — software outcomes
//! emerge from collaboration and prior work; individual attribution is
//! usually false precision that discourages collaboration.
//! - **Treating quality as separate from performance** — a feature that
//! ships on time but causes a wave of incidents did not perform well,
//! even though an output-only view would count it as delivered.
//! - **Ranking teams competitively on performance data** — invites gaming
//! and morale damage; the productive use is deciding where to invest or
//! investigate, never a competitive ranking.
//! - **Forcing a direct-outcome metric onto platform or enabling teams** —
//! their contribution is often several steps removed from any single
//! customer-facing metric; measure their effect on the teams they
//! enable instead.
//!
//! ## Sources
//!
//! - Chapter 3.3, Performance metrics and outcome proxies.
//! - Forsgren, Storey, Maddila, Zimmermann, Houck, and Butler, "The SPACE of
//! Developer Productivity," *ACM Queue* (2021).
//!
//! Topic doc: software-engineering-metrics/locales/en-001/chapters/03-03-performance-metrics-and-outcome-proxies.md
/// The number of independent signals, out of those checked, that indicate
/// positive performance.
///
/// Each `bool` in `signals` represents one independent signal already
/// evaluated by the caller (e.g. "did change failure rate improve",
/// "did defect-escape rate improve", "did adoption rise"), `true` if that
/// signal points to good performance. This function only counts how many
/// agree; it does not itself decide what counts as a signal.
///
/// # Arguments
///
/// * `signals` — one `bool` per independent performance signal checked,
/// `true` if that signal is positive.
///
/// # Returns
///
/// The count of `true` signals.
///
/// # Examples
///
/// ```rust
/// use software_engineering::performance_metrics::converging_signal_count;
///
/// let signals = [true, false, true, true];
/// assert_eq!(converging_signal_count(&signals), 3);
/// assert_eq!(converging_signal_count(&[]), 0);
/// ```
/// Whether enough independent signals converge to trust a performance
/// conclusion, per the chapter's "no single one is reliable alone"
/// principle.
///
/// True iff [`converging_signal_count`] is at least 2 — a single positive
/// signal is never treated as sufficient evidence on its own.
///
/// # Arguments
///
/// * `signals` — one `bool` per independent performance signal checked,
/// `true` if that signal is positive.
///
/// # Returns
///
/// `true` if two or more signals are positive.
///
/// # Examples
///
/// ```rust
/// use software_engineering::performance_metrics::has_sufficient_converging_evidence;
///
/// assert!(!has_sufficient_converging_evidence(&[true]));
/// assert!(has_sufficient_converging_evidence(&[true, true]));
/// assert!(has_sufficient_converging_evidence(&[true, false, true]));
/// ```