Home‎ > ‎

N Examples of Why Time Estimates are Always Wrong

Some of these verge on the comical, but unfortunately all come from the real world.

Technical Examples

  1. It takes a .Net developer an average of 1.5 hours to discover that you can't pass command-line parameters to an application published with ClickOnce without an HTTPD, and then 5 hours to redesign his program to work around it
  2. It takes a CocoaTouch developer about 1 hour to discover that the reason a "Done" button isn't showing up on the iPhone's numeric keypad isn't because he didn't implement the UITextFieldDelegate protocol, or make the right connections in Interface Builder, but because Apple didn't add that button to UIKit in the first place. It'll then take another 8 hours for the company and its UI designers to figure out what to do instead, and 2-3 more hours on top of that to implement it
  3. About 5 hours of debugging time elapse before it becomes clear that a third-party component isn't thread safe, then 16 hours to research a replacement and 48 hours to redesign the program to the new API
  4. Problems updating a GUI in a multithreaded application aren't discovered until about halfway into development, and an average of 4 hours are spent re-plumbing a small application to run an update on the GUI's thread
  5. You don't discover how slow the SOAP API is until you begin testing it with real data and run into chronic timeouts. Now you have to spend 2 or 3 days redesigning the client to break-up requests into manageable chunks
  6. "Technical Debt" (hacks, workarounds, compromised design) multiplies the time required for any maintenance task, and the multiplier will increase over time until the program is refactored
  7. Any house that develops its own utility classes and shortcuts will find about 10% or more of their code is made obsolete by a new version of the framework, and they will either have to refactor to use the new feature, or spend time training new employees to do it the homebrew way
  8. You're halfway through development when you learn that the algorithm you invented was patented by someone else, and your company can't afford to license it
  9. A security vulnerability has forced you to upgrade the platform your web app runs on, but the upgrade made a subtle change to the way locale is set. Now the currency conversion is broken, and it takes 8 hours of intense debugging before you realize it was the difference between [setlocale currency="en_US"] and [setlocale en_US]

HR / IT Examples

  1. HR's mid-project switch to ADP's "ezLaborManager" for its time-clock requires the developer to spend an extra 5 minutes per day to fire-up a copy of Internet Explorer in order to clock-in and clock-out, because ADP hasn't heard of WebKit, Chrome, or Safari
  2. It takes an average of 12 minutes to patch the latest vulnerability in Internet Explorer, 7 minutes to shut-down eight instances of Visual Studio, 3 minutes to reboot, and 3 hours to run a virus scan on the whole machine
  3. IT's non-negotiable mandatory anti-virus software slows down compilation time from 1 minute to 45
  4. For each programmer sharing the same office as another--and who isn't doing pair programming--both the estimate and the margin of error on the estimate can be doubled
  5. For each source of noise above 40 decibels (people talking on the phone, boxes being moved, construction equipment, radios, etc) the estimate and margin of error can be doubled
  6. The programmer who was fired for poor attendance mid-project walked out the door with 5 months of planning in his head, and his replacement requires two weeks from each of three programmers in order to understand the purpose of the project, the codebase, and the enterprise architecture
  7. "It seems that there have been some problems logging into our site. Try again in a bit." 

Client / Management Examples

  1. It costs an average of 20 minutes lost productivity every time a manager interrupts a developer to ask "What are you working on?"
  2. 4 hours are lost for each meeting that takes place anywhere between 11am and 3pm, in addition to the time spent in the meeting, because nothing serious gets done when the developer is anticipating a fixed interruption
  3. About a week of development time is lost whenever someone from marketing makes a fuss about adding "a trivial feature that'll only take 1 hour" so he can close a sale
  4. Most clients will not provide the most important requirement until a project is two-thirds developed. They will not even realize it was a requirement until they begin to see proofs
  5. Any given proof has only a 20% chance of being reviewed by the client at the time it's submitted, and a 90% chance that the client will request changes to the proof after 1 week has already elapsed
  6. The client wants you to add a feature that is potentially anticompetitive, so they insist that you can't discuss it in email, bug tracking software, scheduling software, or anything else that could be gathered by a lawyer with a subpoena