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

“The further a project progressed, the more accurate the estimates for the remaining effort and time became”

Make sense?
 

WordPress 2.9 Highlights

* Global undo/”trash” feature
* Built-in image editor
* Batch plugin update and compatibility checking
* Easier video embeds
* Over 500 tickets, bugs and enhancements

I have found this “old” movie we made back in 2002 during my work at Mercury to “educate” new employees on our code review procedure.

p.s. Raz Yalov was nominated for best supporting actor that year ;)

Enjoy…

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

I have also copy-pasted the presentation transcript below…

• The Golden Rules of Code Review
  • Do a self-review first
  • Stick to the requirements
  • If you need to explain it, document it!
  • It’s about the code – not about you!
  • Unit testing
• Do a self-review first
  • Have you checked all extreme cases?
  • Is your solution KISS?
  • Is your code self-explanatory?
  • Check it as if it was written by someone else
  • Ask yourself the questions you think you are about to be asked…
• Keep It Simple Stupid…
• Stick to the requirements
  • Make sure all aspects of the requirements are filled
  • Make sure you have tested both trivial and extreme cases
  • Document all thoughts and limitations in the code
  • Reference the requirements documents from your code
  • I18N – make sure the code supports multilingual capability where needed
• Documentation
  • Document your files and your functions
  • Give informative comments
  • Explain the logic behind your decisions
  • If you did something that is not logical or intuitive, explain why
  • If you learned historical info while learning the code, document it (be creative :)
  • Follow a standard documentation format
  • When possible, use known design patterns and document the design pattern you chose
• Unit Testing
  • Make sure your unit test is part of the change
  • If you can’t automate the test, check-in a manual procedure to run it
  • Make sure all aspects of the requirements are covered by the tests
  • Document all the tests you wanted to do but couldn’t
  • Test the I18N behavior of your code
• The Code Review Life Cycle
  • “Self-review” your code
  • Schedule a code review
  • Schedule enough time for both people involved
  • When possible, schedule for a time during the morning
  • Split the review into a few sessions, if needed
  • Switch your mind to “listener” mode
  • Write down all comments
  • After the code review is done, apply the necessary fixes and schedule a second review if needed
  • Check-in your changes
• Code Review Tips
  • When you program, remember the last code review
  • If you disagree with the reviewer, invite a 3rd person to review and decide
  • In special cases, invite special guests to review your code
  • When change is small/simple/intuitive, do an “e-review” by mailing your change to the reviewer(s)
  • When self-reviewing, fix mistakes on the spot… :)

***********************************************************************
*** keep it simple and make sure it answers all the requirements ***
***********************************************************************

• Reverify your Requirements
  • Functional specification, use cases and requirements are clear and publicly documented
  • Technical Requirements
  • Performance requirements
  • Security requirements
  • Resources (CPU, Memory, Storage, IO) consumptions limits
  • Audit requirements
  • Out of scope – What does the component NOT do? What NOT support?
  • Future extendibility of the component (options for future extension, generic features etc.)
• High Level Design
  • Main components involved
  • Main Data flows
  • Components and sub-systems and how they relate to the component
  • Which sub-systems does it communicate with (e.g. Relation Façade)
  • Communication mechanisms (e.g. HTTP, WCF)
  • Which subsystems it is dependent on (e.g. Database, Gigaspaces) – What are the requirements?
  • Which sub-systems depend on it (e.g. App.) – What is the expectation?
• Architectural Strategy
  • High availability and load balancing
  • Error detection, fault and recovery
  • Logging and statistics gathering
  • Capacity limitation, planning & resource management:
    • Memory consumption and management policies
    • CPU usage management
    • IO requirements
    • Storage requirement
• Technical Assumptions
  • Limitations
  • Compromises
    • What does this design compromise? (Security, high availability, capacity, performance, quality…)
    • What are the engineering tradeoffs of this design, and why was the current design chosen?
  • Risks and weak points
• Operation
  • Backward compatibility
  • Logging and Monitoring
  • Administration issues
  • Deployment issues:
    • How to deploy (e.g. can it be part of the regular release package?)
    • Required downtime?
    • Deployment risks?
    • Rollback capability
• Testing strategy
  • What to focus on (80/20)
  • Functional test plan review
  • Deployment, environments, and setups
  • Fault and recovery
  • Load and capacity planning
• Execution plan (phases, timeline, milestones, critical path, dependencies etc.)

Please comment if you think I  forgot something…

Recently, I have encountered an interesting paper (2006) about Chubby – Google’s (Paxos based) distributed lock service.
I was especially amazed by the observations made on the Google engineering capabilities and mindset inside a “formal” research publication.

Although one can easily get into a cynical state of mind reading this paper… I feel that this “pragmatic view” which combines a deep architectural and algorithmic know-how with keen understanding of the social factor in software development is exactly the key to create legendary software.

Anyway, very well written – highly recommended reading…

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

“Our developers sometimes do not plan for high availability in the way one would wish. Often their systems start as prototypes with little load and loose availability guarantees; invariably the code has not been specially structured for use with a consensus protocol. As the service matures and gains clients, availability becomes more important; replication and primary election are then added to an existing design.”

“Developers are often unable to predict how their services will be used in the future, and how use will grow.  A module written by one team may be reused a year later by another team with disastrous results … Other developers may be less aware of the cost of an RPC.”

“Despite attempts at education, our developers regularly write loops that retry indefinitely when a file is not present, or poll a file by opening it and closing it repeatedly when one might expect they would open the file just once.”

“Developers rarely consider availability. We find that our developers rarely think about failure probabilities.“

“Developers also fail to appreciate the difference between a service being up, and that service being available to their applications.“

“Unfortunately, many developers chose to crash their applications on receiving [a failover] event, thus decreasing the availability of their systems substantially”

I might be getting a little too old, visionless, pragmatic or pessimistic for this but I find it very hard to travel to the promised lala land, Gartner’s calls “peak of inflated expectations”.

When I encounter a new “Technology Triggers”, I skip right to the “Trough of Disillusionment” without really passing through the promising “peak”…

e.g. Hype Cycle for Emerging Technologies | Gartner, 2009 – Am I missing something here?

p.s. I do think Technology Triggers are very good for SEO and I will update you if it will work… ;)

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Human Augmentation, 3D Flat Panel Displays, Quantum Computing, Context Delivery Architecture, Video Search, Behavioral Economics, Mobile Robots, Surface Computers, Augmented Re4ality, 3D Printing, Internet TV, Wireless Power, Cloud computing, E-Book Readers, Social Software Suites, Micorblogging, Green IT, Video Telepresence, Mesh Networks, Online Video, Home Health Monitoring, Public Virtual Worlds, RFID, Social Network Analysis, Web 2.0, Idea Management, Tablet PC, Wikis, Corporate Blogging, SOA, Location Aware Applications, Speech Recognition etc.

* Gemba (現場) in Japanese means “the actual place” or “the real place”
* Kaizen (改善) in Japanese means “improvement”

In business, Gemba refers to the place where value is created and the general notion is that the best improvement ideas will come simply from going to the Gemba (‘bottom-up’ vs. ‘top-down’)

The ‘Gemba Walk’ is an activity that takes management to the front lines to look for waste and opportunities a.k.a. to practice Gemba Kaizen which is similar to the “western” concept of MBWA (Management by Walking Around)

My view

As I have posted before “To master (/control) a software project you must be able to breathe the project – inhale the chaotic butterfly movements around you and exhale with the needed adjustments…” (The Software Chaos | Feb. 2008)

Although we wish it will be different… the best optimizations are “simply” very deep into the details and I have found out that a daily practice of ‘Gemba Walk’ can be very helpful to your project “well-being” (and I must admit that it took me several years to find out that my weird walk actually had a Japanese name/theory ;)

“less important than a gnat’s toot in a hurricane” :)

Seven tips for an healthy ‘Gemba Walk’ / MBWA

1. Visit everyone
2. Go alone – Daily standup meetings aren’t enough
3. Don’t bypass middle management e.g. don’t change priorities, requirements or design
4. Observe, ask and LISTEN
5. Be genuine, have fun and strive to catch your engineers doing something right and not something wrong (you are not the “fun-police” ;)
6. Share your dreams and vision
7. Don’t “disturb” the Gemba – Timing is everything…

What next?

1. Correlate the Gemba / ‘bottom-up’ observations with your ‘top-down’ understanding
2. Identify waste, risks and opportunities
3. Kaizen – Improve and optimize accordingly

Good Luck!



________________________________________________
Random News from BBC – Gauguin ‘cut off Van Gogh’s ear’

“Vincent van Gogh did not cut off his own ear but lost it in a fight with fellow artist Paul Gauguin in a row outside a brothel”

“imagine that your mother-in-law believed her daughter could do better… and then imagine that she moved in with you… that’s what Scrum is like”

Think about it…

Assuming we shouldn’t aim to completely avoid all errors in software development (since this is an inherent part of any human creation) but rather to spot them as quickly as possible before they become real problems.

And… since Scrum is indeed a very good “tool” to bring the problems in-your-face without any mercy in a daily manner.

So without even getting into the continuous improvement possibilities with mother-in-laws, I really liked the Mother-In-Law allegory :)

By the way, with great anticipation I have proudly joined the Haiku contest @ the famous Ktorium – Wish me luck! :)

WordPress 2.8 Highlights

* Speed!!!
* Theme Browser and Installer
* Ability to add Custom Headers
* New drag-and-drop widgets admin interface and new Widgets API
* New ways to customize dashboard widgets
* Syntax highlighting and function lookup built into plugin and theme editors
* Configurable Views on Management Pages
* Faster Loading Admin Pages