There is a rule Leonardo da Vinci wrote in his notebooks around 1508 that most people have never heard of. It isn't about painting or anatomy. It's about trees.
He noticed something that sounds obvious once you see it, and impossible to un-see after: at any point on a tree, if you cut every branch at that height and measured their cross-sections, the total area of all those branches together would equal the cross-section of the trunk below them. Every single time. On every tree.
In his words:
"All the branches of a tree at every stage of its height when put together are equal in thickness to the trunk below them."
The tree doesn't "lose" anything as it branches. The trunk's full capacity distributes itself perfectly into the branches. The branches distribute into sub-branches, those into twigs, and so on — each split preserving the total exactly. Nothing escapes, nothing is wasted. The complexity at the top equals the foundation at the bottom.
You've heard this before. Someone demos a feature that looks finished. Transitions are smooth, the data loads, the button works. It feels like 90% done. Maybe it is 90% done.
Then you spend the next three months on that last 10%.
Tom Cargill of Bell Labs put it plainly. Jon Bentley popularized it in his 1985 Programming Pearls column in Communications of the ACM:
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."
It adds up to 180%. That's the joke — and the point. Cargill called it the Rule of Credibility.
Douglas Hofstadter captured the recursive despair of this in Gödel, Escher, Bach (1979):
"Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law."
The law references itself because that's the nature of the problem. You already know you're going to underestimate. You correct for it. You still underestimate.
The 90-90 rule and Hofstadter's Law are symptoms. The tree is the diagnosis.
When you look at a finished feature, you're looking at the visible branches — the UI, the happy path, the demo. But the trunk below it is everything that has to hold it up: error handling, edge cases, loading states, mobile layout, accessibility, security, performance under load, the weird thing that only happens in production, the integration test that only fails on Tuesdays, the PM feedback, the design revision, the re-revison.
The trunk is never smaller than the sum of all the branches. That's not a law of bad planning — it's a law of nature.
The work you can see is not the work that exists. The visible complexity is the branches. The hidden complexity is the trunk. They are always equal.
This pattern shows up everywhere the words "almost done" appear:
In each case, the later stages aren't slower because people got lazy or distracted. They're slower because the complexity of the remaining work is equal to the complexity of everything already done. The trunk doesn't shrink just because the branches have grown.
There's an older version of this problem. Zeno of Elea, around 450 BC, proposed the paradox of the arrow: to travel any distance, you must first travel half of it. Then half of what remains. Then half of that. You never arrive — there are always infinitely many halves left.
The 90-10 version is cruder but more honest about how work actually feels. You do the first 90% and feel like you're almost there. The remaining 10% is half again. Then half of that. The arrow never lands.
Here is what a drawing of this idea looks like — a prompt to generate it:
Pencil sketch of a bare deciduous tree in winter, seen from a slight distance. At five different heights on the tree, a horizontal dotted line crosses all branches at that level. At each line, small labeled cross-sections show the circular cuts of every branch at that height. An annotation shows that the sum of all cross-section areas at each height equals the cross-section of the trunk just below it. The image is precise and technical — like a diagram from a naturalist's notebook — not decorative. No leaves. No background. Clean lines. The tone is observational, almost clinical.
The tree problem isn't solvable by working harder or planning more carefully. It's a structural fact about complex work. What changes when you understand it:
Da Vinci noticed his rule about trees without knowing why it was true. It took until 2011 for Christophe Eloy at Aix-Marseille University to publish a mechanical explanation: trees maintain this proportion because it's the optimal structure for resisting wind stress. The branches grow this way because any other ratio would break them.
Your project maintains its proportion for the same reason. The later stages are load-bearing. If they weren't, they wouldn't still be there.