“In 210 BC, a Chinese commander named Xiang Yu led his troops across the Yangtze River to attack the army of the Qin (Ch’in) dynasty. Pausing on the banks of the river for the night, his troops awakened in the morning to find to their horror that their ships were burning. They hurried to their feet to fight off their attackers, but soon discovered that it was Xiang Yu himself who had set their ships on fire, and that he had also ordered all cooking pots crushed.”

“Xiang Yu explained to his troops that without the pots and the ships, they had no other choice but to fight their way to victory or perish. That did not earn Xiang Yu a place on the Chinese army’s list of favorite commanders, but it did have a tremendous focusing effect on his troops (as they grabbed) their lances and bows, they charged ferociously against the enemy and won nine consecutive battles, completely obliterating the main-force units of the Qin dynasty”

Prof. Ariely is making a point about the advantage of making a choice to focus by closing other doors/options/opportunities.

Joshua Baer had an interesting allegory to the startup world in his “Necessity is the mother of Invention” post

“This is similar to when a bootstrapper enters the Valley of Death* and commits to their venture, but before they are making money and cash flow positive. They are forced to figure out how to make it work with what they’ve got. The timeline is not completely in their control.

We’re always tempted to leave ourselves an escape route or path of retreat. And usually that’s a good idea. But sometimes there aren’t enough resources to mount the attack and cover the retreat. In order to be successful sometimes you have to commit the resources to what you believe in because the retreat option isn’t acceptable. Sometimes once you head down a path there is just no turning back, so you might as well commit all of your resources to getting to the end”

Well… this is true but since I am a notorious pessimist and usually like my options open, I have continued reading about this fine gentlemen (a.k.a. Xiang Yu)

I learned that indeed in the beginning of the civil war Xiang Yu was winning but with his rude manners, arrogance and lack of political vision, the tide turned against Xiang Yu and in the end he lost the war to Liu Bang.

In 202 BC, when Xiang Yu and his remaining men had their backs against the river while surrounded by Liu Bang’s troops, a boatman on a raft persuaded Xiang Yu to go with him across the river so he can prepare a comeback.
Xiang Yu said, “When I crossed the River and went west, I took with me 8,000 sons and brothers from east of the Yangtze. Now none of them has returned; how can I face the elders east of the Yangtze?” After declining this offer, Xiang Yu turned around, charged against the Han troops, killed over a hundred men, and finally cut his own throat.
Shortly after his death Liu Bang established the Han Dynasty.

Three concluding facts about Xiang Yu:

• Xiang is popularly viewed as a leader who possesses great courage but lacks wisdom, and his character is aptly summarized using the Chinese idiom “Yǒu Yǒng Wú Móu” (有勇無謀) - “Having Courage but No Strategies” (or  to be foolhardy or to be more brave than wise or to have reckless courage…)
• Xiang’s battle tactics were studied by future military leaders while his political blunders served as cautionary tales for future rulers
• Xiang Yu is also the kind general that raided the Terracotta** tomb less than five years after the death of the First Emperor – Xiang’s army was looting of the tomb and structures holding the Terracotta Army, as well as setting fire to the necropolis and starting a blaze that lasted for three months.

“Yǒu Yǒng Wú Móu” (有勇無謀) - “Having Courage but No Strategies” - Think about it…! ;)

* Valley of Death – A slang phrase to refer to the period of time from when a startup receives an initial capital contribution to when it begins generating revenues.
During the death valley curve, additional financing is usually scarce, leaving the firm vulnerable to cash flow requirements.

** The Terracotta Army or the “Terra Cotta Warriors and Horses“, is a collection of terracotta sculptures depicting the armies of Qin Shi Huang, the First Emperor of China
The figures, dating from 210 BC, vary in height according to their roles, with the tallest being the generals. The figures include warriors, chariots, horses, officials, acrobats, strongmen, and musicians.
Current estimates are that in the three pits containing the Terracotta Army there were over 8,000 soldiers, 130 chariots with 520 horses and 150 cavalry horses, the majority of which are still buried in the pits.
There is also a legend that the terracotta warriors were real soldiers, buried with Emperor Qin so that they could defend him from any dangers in the next life.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

p.s. Prof. Ariely also recommends another role model for door closing – Rhett Butler for his supreme moment of unpredictable rationality with his astonishing elan, “Frankly my dear, I don’t give a damn”

Underestimation is Underestimated (a.k.a. Overestimation is Overestimated)

Sometimes it seems like we have an underestimation gene embedded really deep in our cognition but for some “obvious” reason (e.g. underestimation! :) most manager will rather “fight” overestimation and *not* underestimation.

Disclaimer: I have originally estimated this post will take ~33 min but it took me ~240% more time… (this is why I prefer to tweet lately ;)

Six annoying facts about our (/homo sapiens) planning or estimation “skills”:

• We are basically optimistic and have strong desire to please
• We tend to have incomplete recall of previous experience
• We tend to have focus bias when estimating e.g. estimating only the coding phase estimations which is only ~14-37% of the required work
• We tend to postpone what we can a.k.a. “The Student Syndrome”  (Eliyahu M. Goldratt, Critical Chain)
• “It always takes longer than you expect, even when you take into account Hofstadter’s Law” (Douglas Hofstadter, Godel, Escher, Bach: An Eternal Golden Braid)
• We tend to underestimate task completion times – a.k.a. The planning fallacy

Overestimation is Overestimated

“The developers say that this project will take 6 months… I think there’s some padding in their estimates and some fat that can be squeezed out of them…we also need to instill a sense of urgency in the development team… so I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will deliver in the 6 months they originally estimated” (Does this ring *any* bell???)

Four reasons on managers tendency to “fight” overestimations:

• Underestimation (see above :) | “The feature estimation seems bloated” | “Isn’t it 20 min work?” | “Just add another index to the %$^&ing table?” | “It is only one more button…”
• Unreasonable time constraint | “We need this feature yesterday” | “Nothing is impossible for the man who doesn’t have to do it himself” (A. H. Weiler)
• True belief that Parkinson’s “Law” is really a law – “Work expands so as to fill the time available for its completion”
• “The Student Syndrome”  (see above)

So… if feature estimation seems bloated, managers and other project stakeholders fear that Parkinson’s Law and the Student Syndrome would kick in and therefore consciously squeeze the estimates to try to control it (a.k.a. “The Parkinson’s Squeeze”) and when we squeeze where it isn’t needed or was squeezed already, it immediately lead to… UNDERESTIMATION (!!!)

Underestimation is Underestimated

Underestimation creates numerous problems – some obvious, some not so obvious.

• Reduced effectiveness of project plans – Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work. If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems but numerous studies have found that software estimates are often inaccurate by 100% or more (see above). When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.
• Statistically reduced chance of on-time completion – Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.
• Poor technical foundation leads to worse-than-nominal results. A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take much longer than it would have taken with an accurate estimate.
• Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project… below are some examples when the important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals, these extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately
  • More status meetings with upper management to discuss how to get the project back on track
  • Frequent re-estimation, late in the project, to determine just when the project will be completed.
  • Apologizing to key customers for missing delivery dates (including attending meetings with those customers).
  • Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready on time, the software itself could be used, and no interim release would be necessary.
  • More discussions about which requirements absolutely must be added because the project has been underway so long.
  • Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the schedule pressure.

Tip of the day
Never intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through control, tracking and *mentoring* but not by bias.

****************************************

More related posts (a.k.a. people who read this post also read these posts)

• Software projects anxiety
• The Stockdale Paradox the Pessimistic Developer paradigm
• In Broken Images
• The Dunning Kruger Effect
• The Cone of Uncertainty in Pastel

Justin Kruger & David Dunning have tested and verified the following predictions:

• Incompetent individuals tend to overestimate their own ability and performance 
• Incompetent individuals fail to recognize genuine skill in others (it takes one to know one ;)
• Incompetent individuals fail to recognize the extremity of their inadequacy (“One puzzling aspect of our results is how the incompetent fail, through life experience, to learn that they are unskilled”)
• If they can be trained to substantially improve their own skill level, these individuals can recognize and acknowledge their own previous lack of skill (There is still some hope)

Do you have the confidence that this post isn’t about you? 

Think again… (!!!) - “ignorance more frequently begets confidence than does knowledge” (Charles Darwin)

Do you think this post is about you?

Might be considered vain but interesting enough, the same research have shown that the top performers tended to underestimate their own performance compared to their peers (see chart below). 

So… if you find this post boring, obscure, stupid, annoying, poorly written or inappropriate than please keep in mind it isn’t something I have committed knowingly.

2019-1972=47 (!!!)

Someone wise once gave this as a metaphorical example for a common engineers disorder, he called experience-anxiety-disorder, claiming that NASA stopped sending manned missions to the moon since they now know much more about the complexity and risk with doing this.

During the early seventies, it was a nice, naive working implementation but when NASA engineers started thinking about the next release they have built a five-decades-project-plan simply because they considered all the technological experience they have gained into large complexity buffers.

The Moral Lesson
Keep-it-simple can-do-approach and don’t over-complicate things with the long-tail-little-details when not needed or the project will take 5 decades to finish.

How do you know you are have an experience-anxiety-disorder?
If someone ask you to add a button to change the database schema and this make you feel a mixture of fear, apprehension, heart palpitations, nausea, chest pain, shortness of breath and headache.

What to do?
Sit down and relax, drink a cup of water and then add the damn button!

Last Long-Tail-Detail
Well… I don’t want to ruin this lovely moral lesson with the long-tail-little-detail but the real facts behind this 47 years gap were politics and money (as always) and not that NASA engineers got a severe experience-anxiety-disorder.

Google Trends (a.k.a. my experiment – part IV – Almost forgot…)

• Betty Casey
  
• Most Haunted Life
  
• Piercing & Tattoos
  
• Madonna
  
• World War III (…)
  

“We have all some experience of a feeling, that comes over us occasionally, of what we are saying and doing having been said and done before, in a remote time – of our having been surrounded, dim ages ago, by the same faces, objects, and circumstances – of our knowing perfectly what will be said next, as if we suddenly remember it!” - Charles Dickens

In recent years, déjà vu has been subjected to serious psychological and neurophysiological research. The most likely explanation of déjà vu is that it is not an act of “precognition” or “prophecy”, but rather an anomaly of memory; it is the impression that an experience is “being recalled” which may result from an overlap between the neurological systems responsible for short-term memory and those responsible for long-term memory.

In other words, “déjà vu” is yet another careless data inconsistency situation due to poor synchronization mechanism and hectic multithreaded race-condition incidents a.k.a. “Dark-Voodoo” bugs (e.g. “déjà vu” ;-)

—

There are many ways in which the deja experience may manifest: deja entendu – already heard; deja eprouve - already experienced; deja fait – already done; deja pense – already thought; deja raconte – already recounted; deja senti – already felt, smelt; deja su - already known (intellectually); deja trouve – already found (met); déjà vécu - already lived; deja voulu – already desired; deja arrive – already happened; deja connu – already known (personal knowing); deja dit - already said/spoken (content of speech); deja goute - already tasted; deja lu – already read; deja parle – already spoken (act of speech); deja pressenti – already sensed; deja rencontre – already met; deja reve - already dreamt; deja visite – already visited and my recent favorite invention: déjà posté – already posted…