It seems to be common invoke Laws in place of actual facts when trying to support a point. Here's two recent ones I've encountered with some Agile and #NoEstimates advocates. Two of my favorite are:
- Goodhart's Law
- Hofstadter's law
These are not Laws in the same way as the Laws of Physics, Laws of Chemistry, Laws of Queuing theory - which is why it's so easy to misapply them, misuse them, use them to obviscate the situation and hide behind fancy terms which have no meaning to the problem at hand. Here's some real laws.
- Newton's Law(s), there are three of them:
- First law: When viewed in an inertial reference frame, an object either remains at rest or continues to move at a constant velocity, unless acted upon by a net force.
- Second law: In an inertial reference frame, the vector sum of the forces F on an object is equal to the mass m of that object multiplied by the acceleration vector a of the object: F = ma.
- Third law: When one body exerts a force on a second body, the second body simultaneously exerts a force equal in magnitude and opposite in direction on the first body.
- Boyle's Law - For a fixed mass of gas at constant temperature, the volume is inversely proportional to the pressure. pv = Constant.
- Charle's Laws - For a fixed mass of gas at constant pressure, the volume is directly proportional to the kelvin temperature. V = Constant x T
- 2nd Law of Thermodynamics states that the total entropy of an isolated system always increases over time, or remains constant in ideal cases where the system is in a steady state or undergoing a reversible process. The increase in entropy accounts for the irreversibility of natural processes, and the asymmetry between future and past.
- Little's Law - which is l = λw, which asserts that the time average number of customers in a queueing system, l, is equal to the rate at which customers arrive and enter the system, λ, times the average sojourn time of a customer, w. And just to be clear the statistics of the processes in Little's Law are IID - Independent, Identicially Distribution and Stationary. Rarely the case in software development, where Little's Law is misused often.
Misuse of Goodhart's Law
This post, like many of other posts, was stimulated by a conversation on social media. Sometimes the conversations trigger ideas that have laid dormant for awhile. Sometimes, I get a new idea from a word or a phrase. But most of the time, they come from a post that was either wrong, misinformed, or worse misrepresenting no principles.
The OP claimed Goodhart's Law was the source of most of the problems with software development. See the law below.
But the real issue with invoking Goodhart's Law has several dimensions, using Goodhart's Law named after the economist who originated it, Charles Goodhart. Its most popular formulation is: "When a measure becomes a target, it ceases to be a good measure." This law is part of a broader discussion of making policy decision on macro economic models.
Given that the structure of an econometric model consists of optimal decision rules of economic agents, and that optimal decision rules vary systematically with changes in the structure of series relevant to the decision maker, it follows that any change in policy will systematically alter the structure of econometric models.
What this says is again when the measure becomes the target, that target impacts the measure, changing the target.
So first a big question
Is this macroeconomic model a correct operational model for software development processes - measuring changes the target?
Setting targets and measuring performance against that target is the basis of all closed loop control systems used to manage projects. In our domain this control system is the Risk Adjusted Earned Value Management System (EVMS). EVM is a project management technique for measuring project performance and progress in an objective manner. A baseline of the planned value is established, work is performed, physical percent complete is measured, and the earned value is calculated. This process provides actionable information about the performance of the project using Quantifiable Backup Data (QBD) for the expected outcomes of the work, for the expected cost, at the expected time all adjusted for the reducible and irreducible uncertanties of the work.
Without setting a target to measure against, we have:
- No baseline control.
- No measures of effectiveness.
- No measures of performance.
- No technical performance measures.
- No Key Performance Parameters.
With no target and no measures of progress toward the target ...
We have no project management, no program controls, we have no closed loop control system.
With these missing pieces, the project is doomed on day one. And then we're surprised it runs over cost and schedule, and doesn't deliver the needed capabilities in exchange for the cost and time invested.
When you hear Goodhart's Law is the cause of project failure, you're likely talking to someone with little understanding of managing projects with a budget and do date for the needed capabilities - you know an actual project. So what this means in economics and not in project management is ...
... when a feature of the economy is picked as an indicator of the economy, then it inexorably ceases to function as that indicator because people start to game it. - Mario Biagioli, Nature (volume 535, page 201, 2015)
Note the term Economy, not cost, schedule, and technical performance measures of projects. Measuring the goals and activities of monetary policy Goodhart might be applicable. For managing development of products with other people's money, probably not.
Gaming of the system is certainly possible on projects. But unlike the open economy, those gaming the project measures can be made to stop, with a simple command. Stop gaming or I'll find someone else to take your place.
Misuse of Hofstadter's Law
My next favorite misused law is this one, which is popular among the #Noestimates advocates who claim estimating can't be done.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law — Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
Hofstadter's Law is about the development and use of self-referencing systems. The statement is about how long it takes is itself a self-referencing statement. He's speaking about the development of a Chess playing program - and doing so from the perspective of 1978 style software development. The game playing programs use a look ahead tree with branches of the moves and countermoves. The art of the program is to avoid exploring every branch of the look ahead tree down to the terminal nodes. In chess - actual chess, people - not the computer - have the skill to know what branches to look down and what branches to not look down.
In the early days (before 1978) people used to estimate that it would be ten years until the computer was a world champion, But after ten years (1988) it was still estimated that day was still ten years away.
This notion is part of the recursive Hofstadter's Law which is what the whole book is about. The principle of Recursion and Unpredictability is described at the bottom of page 152.
For a set to be recursively enumerable (the condition to traverse the look ahead tree for all position moves), means it can be generated from a set of starting points (axioms), by the repeated application of rules of inference. Thus, the set grows and grows, each new element being compounded somehow out of previous elements, in a sort of mathematical snowball. But this is the essence of recursion - something being defined in terms of simpler versions of itself, instead of explicitly.
Recursive enumeration is a process in which new things emerge from old things by fixed rules. There seem to be many surprises in such processes ...
So if you work on the development of recursive enumeration based software systems, then yes - estimating when you'll have your program working is likely going to be hard. Or if you work on the development of software that has no stated Capabilities, no Product Roadmap, no Release Plan, no Product Owner or Customer that may have even the slightest notion of what Done Looks like in units of measure meaningful to the decision makers, then probably you can apply Hofstadter's Law. Yourdan calls this type of project A Death March Project - good luck with that.
If not, then DO NOT fall prey to the misuse of Hofstadter's Law by those likely to not have actually read Hofstadter's book, nor have the skills and experience to understand the processes needed to produce credible estimates.
So once again, time to call BS, when quotes are misused
