吉尔布定律
任何需要量化的事情，都可以找到一种比完全不测量更好的测量方式。
显示原始英文内容
Gilb's Law
Anything you need to quantify can be measured in some way better than not measuring it.
Takeaways
- It is better to have some data or metric on a phenomenon than to be completely blind, as long as you understand the metric's limitations.
- In contrast to Goodhart's Law, which warns about misuse of metrics, Gilb's Law reminds us not to throw out metrics entirely.
- Start with a basic measure and refine it over time. The act of measuring helps teams focus and identify trends.
- Even an approximate or indirect measurement is better than none.
Overview
Gilb's Law responds to the paralysis that Goodhart's Law can cause. This law asserts that even an approximate or indirect measurement is better than none. When something is essential (performance, customer satisfaction, code maintainability), you should attempt to measure it, because otherwise you have no objective feedback.
Gilb's Law is a good reply to the statement "this aspect is unmeasurable so we won't try." For example, measuring "code quality" is difficult, but you can measure indicators such as cyclomatic complexity, lint warnings, or defect rates as partial indicators. More such indicators can paint the bigger picture.
Those metrics won't be perfect, but Gilb's Law suggests that having them gives you some insight and a starting point for improvement, which is better than having no clue at all.
Examples
Measuring developer productivity is notoriously hard (lines of code are poor proxies, story points can be inconsistent). However, you might use deployment frequency or change lead time (as in the DORA metrics for DevOps) as a proxy. They do not capture everything, but they give you actionable data. If deployment frequency decreases, something might be wrong with the pipeline.
Another example is tracking Tech Debt. No perfect measure of tech debt exists. But tracking things like code complexity scores, incident rates, and developer surveys gives you visibility you would not otherwise have. As Peter Drucker said: "We cannot improve what we do not measure."
Origins
Tom Gilb, a consultant and author on software engineering, formulated this law. It complements his other work on quantifying requirements and using metrics in planning, including Planguage and evolutionary project management.
核心含义
“软件质量无法测量”通常不是终点，而是需要进一步拆分问题的信号。虽然不能直接精确测量“可维护性”或“用户信任”，但可以观察变更失败率、恢复时间、缺陷密度和真实任务完成情况。
不完美的测量只要能帮助比较、发现趋势和引导讨论，就比完全凭感觉更有价值。
实践例子
与其争论代码是否“足够稳定”，不如记录发布后的故障率、回滚次数和恢复时间。连续几周的数据可以帮助团队发现趋势并验证改进是否有效。
来源与边界
Tom Gilb 是软件工程度量和演进式规划的重要实践者。这条规律不鼓励制造大量指标，测量本身也应有成本意识并服务于决策。