I posted some comments on the #NoEstimates book awhile back. I have a break this week and would like to sum up Chapter 1.
Chapter 1 Introduction
- Why estimates don't work - Carmen is assigned a project that will make or break the company. Carmen has never managed a project this size.
- This is a classic example used in the book of making seriously bad management decisions.
- Why would the manager assign Carmen that project?
Then comes one of three quotes that are the basis of the argument for NOT estimating. The most egregious is Hofstadter's Law, which says It always takes longer than you expect, even when you take into account Hofstadter's Law
This quote is misused to suggest that estimating can't be done. On page 152 of Gödel, Escher, Bach: an Eternal Golden Braid, Hofstadter explains the context and meaning of Hofstadter's Law.
Hofstadter is 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 designs, 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. Yordan 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 Why Is It Important to call out something like the misuse of a quote? Simple, if you can't get the simple understanding of what someone said, how they meant, and in what context they said it, how can you have a coherent message for the message you're trying to convey? Several other "agile" books do the say they. This is why Agile! The Good, the Hype, and the Ugly is a mandatory read
Some More nonsense quotes Out of Context or Without ANY Context and Bad Management Being Done on Purpose
This Chapter contains many bogus quotes, examples of Doing Stupid Things on Purpose, here are a few examples:
- A Late Change in Requirements is a Competitive Advantage - is only true if that change enhances the value of the product and the cost of that change does not impact the ROI of the product
- 80,000 lines of code won't fit on a 20-page contract - never seen a contract to stated how many lines of code. A simple letter contract for the development of an IT Ticketing systems can be stated in 5 pages of less. Yet another example of stating nonsense with no context.
- Figure 4 shows the inability of the team and management to actually flow the principles of Scrum. This is a picture of a bad scrum team. they need an intervention from a Scrum coach to get them back to actually providing value to their customer
Chapter 1 Ends With the #NoEstimates Argument But Ignores the Uncertainties of all Project Work
If it is so hard to estimate software work, can you predict when a particular project will end? Yes, you can. And that is the right question. Instead of asking how long the project will take, ask instead: “given the rate of progress so far, and the amount of work still left, when will the project end?” Or, a similar question: “Given the rate of progress, how much of the work can be finalized by date X?”
This is possibly the case IIF (If and Only If):
- All the work is of equal effort
- All the work is of equal duration
- All the workers have consistent productivity over the life of the work
- There are no aleatory uncertainties in any of the processes
- There are no epistemic uncertainties in any process, people, or tools
In other words, the work is non-variable, equal size and effort, and the developers work at an unchanging rate, and the arrival of the work is constant. This the definition of a Machine Based process. Not likely ever to be true.
So at the end of Chapter 1, No estimates is based on a set of conditions that are NEVER present on actual project
Intro the Chapter 2
Chapter 2 starts with a scene of sending poor Carmen on a Death March.
- This was not Carmen’s first project, but until now she had managed to give fair estimates on her projects because they were small and somehow similar.
- But this was a different kind of beast. New technologies, new client, new domain, new product.
So does Carmen have any reference classes for making estimates of the new project? How about some models with scaling parameters? How about an understanding of the uncertainties involved in the project? The reducible uncertainties (Epistemic) the irreducible uncertainties (Aleatory) both of which create Risk for the success of the projects. Does Carmen have a Product Roadmap where these uncertainties can be assessed? Does Carmine have a Product Owner, an Agile estimating process? A Release Plan?
Does Carmen have anything she needs for success? Sounds like she's being tossed to the Wolf's in pursuit of a predefined conjecture that estimates can not work. This is the style of writing here. If this is appealing to you - make up a bad situation, where the protagonist is sacrificed to the Gods of Bad Management, then the solution is just as incredible, then keep reading. I'll take a break before Chapter 2 for all these contrived plot twists based on contrived examples of Bad Management.