DEV Community

전규현 (Jeon gyuhyeon)
전규현 (Jeon gyuhyeon)

Posted on

Why Developers Always Miss Deadlines

"How long do you think this will take?"

"Um... probably 3 days?"

A week later...

"Still not done?"

"Almost there... just one or two more days..."

Familiar conversation, right?

Developers missing deadlines isn't due to lack of ability. It's because the human brain is systematically designed to fail when estimating complex tasks.

Shocking Statistics

According to Standish Group's CHAOS Report:

project_outcomes = {
    "On time": "29%",
    "Delayed": "52%",
    "Failed/Cancelled": "19%"
}

average_delay = {
    "Expected": 100,  # days
    "Actual": 189,  # days
    "Overrun": "89%"
}
Enter fullscreen mode Exit fullscreen mode

71% of projects miss deadlines.

5 Reasons Estimation Fails

1. Planning Fallacy

A cognitive bias discovered by Nobel Prize winner Daniel Kahneman.

We always imagine only the best-case scenario:

  • No bugs
  • Requirements won't change
  • No one will get sick
  • Servers won't go down

Reality? Murphy's Law rules.

2. Hofstadter's Law

"It always takes longer than you expect, even when you take Hofstadter's Law into account."

Recursive irony. Even when you expect delay, it delays more.

function estimate(task) {
  const initial = calculateTime(task);
  const buffered = initial * 1.5; // Add buffer
  const reality = buffered * 2; // Still not enough
  return reality;
}
Enter fullscreen mode Exit fullscreen mode

3. Anchoring Effect

Fixated on the first number heard.

PM: "This should take a day, right?"
Developer: (Actually 3 days internally...) "Um... probably 2 days"

The initially suggested "one day" becomes an anchor that distorts estimation.

4. Student Syndrome

When there's time until deadline, we procrastinate.

5 days available:
Day 1-3: "Still plenty of time" (other work)
Day 4: "Maybe start now"
Day 5: "Oh no! Not enough time!"
Enter fullscreen mode Exit fullscreen mode

5. 90% Syndrome

The last 10% takes 90% of the total.

  • 90% complete: Basic feature implementation
  • Remaining 10%: Exception handling, testing, documentation, deployment, bug fixes...

Developer Brain's Estimation Mechanism 

def developer_brain_estimation(task):
    # Step 1: Calculate only coding time
    coding_time = estimate_pure_coding()  # 8 hours

    # Step 2: Unconsciously ignored things
    ignored = {
        "debugging": 0,      # "Won't have bugs"
        "testing": 0,      # "Later..."
        "review": 0,        # "Will pass quickly"
        "documentation": 0,        # "Code is documentation"
        "meetings": 0,        # "It's development time"
        "deployment": 0         # "Just upload it"
    }

    return coding_time  # 8 hours (actually 24 hours)
Enter fullscreen mode Exit fullscreen mode

3-Step Formula for Accurate Estimation

Step 1: Break Down Tasks (Max 4-hour units) 

❌ "Login Feature" (40 hours?)

✅ Breakdown:
- Login UI (2 hours)
- Email Validation (1 hour)
- Password Encryption (2 hours)
- Session Management (3 hours)
- API Integration (2 hours)
- Error Handling (2 hours)
- Testing (3 hours)
Enter fullscreen mode Exit fullscreen mode

Step 2: Three-Point Estimation (PERT) 

def pert_estimation(optimistic, realistic, pessimistic):
    """
    O: Optimistic (when everything is perfect)
    R: Realistic (normal case)
    P: Pessimistic (when everything goes wrong)
    """
    estimate = (O + 4*R + P) / 6

    # Example: Login API
    O = 4  # Best: 4 hours
    R = 8  # Reality: 8 hours
    P = 16 # Worst: 16 hours

    result = (4 + 32 + 16) / 6  # 8.67 hours
    return result
Enter fullscreen mode Exit fullscreen mode

Step 3: Add Buffer 

Development Time: 10 days
├── Focused Development: 7 days (70%)
├── Integration/Debugging: 2 days (20%)
└── Reserve Buffer: 1 day (10%)
Enter fullscreen mode Exit fullscreen mode

Practical Checklist

Check before schedule estimation:

  • [ ] Did you break tasks to 4 hours or less?
  • [ ] Did you include non-development time? (meetings, reviews, docs)
  • [ ] Did you calculate test time separately?
  • [ ] Did you consider dependencies and wait time?
  • [ ] Did you consider team member vacation/sick leave possibility?
  • [ ] Did you apply three-point estimation?
  • [ ] Did you add at least 20% buffer?

Team Estimation Improvement Methods

Planning Poker 

Team members reveal estimates simultaneously:
Developer A: 🃏 5 days
Developer B: 🃏 3 days
Developer C: 🃏 8 days

If difference is large, discuss → reach consensus
Enter fullscreen mode Exit fullscreen mode

Performance-Based Adjustment 

# Analyze past 10 projects
historical_data = {
    "average_overrun": 1.8,  # 1.8x longer
    "standard_deviation": 0.3
}

# Next project estimation
raw_estimate = 20  # days
adjusted = raw_estimate * 1.8  # 36 days
confidence_range = (30, 42)  # ±standard deviation
Enter fullscreen mode Exit fullscreen mode

Conclusion: Honest Estimation Saves Everyone

Before saying "probably 3 days", pause and think.

Is it really 3 days? Or is it wishful thinking?

Secrets of Accurate Estimation:

  1. Break down small
  2. Find hidden work
  3. Apply three-point estimation
  4. Add buffer
  5. Reference past data

Optimistic estimation makes everyone unhappy.
Better to estimate pessimistically and finish early.

Need accurate schedule estimation and project management? Check out Plexo.

Top comments (0)