intellectual-honesty-in-development

name	intellectual-honesty-in-development
description	Apply intellectual honesty principles when debugging errors, reporting project status, and providing time estimates. Use this skill when encountering compiler warnings, preparing progress reports, or negotiating project timelines with management.

Intellectual Honesty in Development

When to Use This Skill

• Debugging and Error Handling: When you encounter errors, warnings, or uncertain situations
• Project Status Reporting: When preparing progress reports or status updates
• Estimation and Negotiation: When providing time estimates and management pressures you to adjust them

Scenario 1: Admitting Errors and Understanding Warnings

Core Principles

1. Never pretend to be an expert - If you don't know something or made a mistake, admit it readily
2. Understand compiler warnings - Don't suppress or ignore warnings; investigate what they point to
3. Understand your program - Never compile code just to "see what happens" without understanding the logic

Warning Signs

• Feeling tempted to compile code to determine whether to use < or <=
• Running programs to verify logic you don't understand
• Ignoring warnings because you think they mean something else

Actions

• When you encounter a warning, investigate the root cause rather than suppressing it
• If you don't understand why code works, return to the design phase
• Admit mistakes quickly and explicitly - everyone will know anyway

Scenario 2: Honest Project Status Reporting

Core Principles

1. Avoid the "90% complete" fallacy - Don't claim 90% completion when you're in the last 50% of time
2. The 90-90 Rule: The first 90% of code takes the first 90% of development time. The remaining 10% takes the other 90%.
3. Provide accurate assessments - Managers appreciate honest observations even when they're not what they want to hear

Communication Guidelines

• Deliver honest observations calmly and privately when possible
• Recognize that management needs accurate information to coordinate development
• If you struggle with progress judgment, study your own work patterns to improve

Scenario 3: Estimation and Negotiation

Core Principle

Estimates are not negotiable. You can refine estimates for accuracy, but negotiating with your boss won't change the time required to develop software.

When Management Pressures You

Use this approach:

"Look, this is what it costs. I can't judge whether it's worth it to the company—that's your job. But I can tell you how long it takes to develop the software—that's my job. I can't 'negotiate' how long it takes; that's like negotiating how many feet are in a mile. You can't negotiate natural laws."

What You CAN Negotiate

If management needs different timelines, negotiate project scope:

• Eliminate features
• Lower performance requirements
• Phase the project development
• Adjust team size (fewer people/longer schedule OR more people/shorter schedule)
• Re-estimate based on the new scope

What NOT to Do

• Never underestimate costs to gain project approval
• Underestimating steals management's authority to make informed decisions

Key Takeaways

• Intellectual honesty builds trust and credibility
• Pretending to know what you don't know damages your reputation
• Accurate information enables better decision-making at all levels
• Negotiate scope, not reality