Project Red Flags
Spot trouble early: These are warning signs that a project is headed for failure. One or two? Pay attention. Multiple? Intervention required.
Requirements Red Flags
- "We'll figure out requirements as we go"
- Requirements change weekly with no process
- No one can explain why a requirement exists
- Requirements conflict with each other
- "The customer will tell us when they see it"
Design Red Flags
- "Let's make it generic for future use cases"
- No trade studies, just gut feelings
- Margins below 10% or completely unknown
- "We'll optimize later" (spoiler: you won't)
- Architecture changes during implementation
Process Red Flags
- No code reviews or peer checks
- Testing happens only at the end
- Documentation is "we'll catch up later"
- Meetings to plan meetings to discuss meetings
- Decisions made by committee, no ownership
Team Red Flags
- Key person is single point of failure
- Engineers padding estimates 3-5x
- Constant firefighting, no time to think
- "That's not my job" mentality
- Finger-pointing instead of problem-solving
Schedule Red Flags
- Schedule created by management, not engineers
- No buffer for integration or testing
- Delivery date set before requirements defined
- Heroic effort required to stay on track
- Schedule slips every week but deadline doesn't move
Customer Relationship Red Flags
- Can't get access to actual end users
- Requirements from sales, not operations
- Customer changes priorities daily
- Every request treated as "scope creep"
- Adversarial relationship, not collaborative
Decision Framework: When to Act
Not all decisions are equal: Know which decisions are reversible (experiment freely) vs irreversible (think carefully). Jeff Bezos calls these "one-way doors" vs "two-way doors."
| Decision Type | Reversible? | How to Decide | Examples |
|---|---|---|---|
| Type 1: Critical & Irreversible | No or very expensive | Slow, deliberate, gather data, review with team | System architecture, hardware platform, major vendor selection |
| Type 2: Important but Reversible | Yes, with moderate effort | Decide quickly, implement, evaluate, adjust if needed | Algorithm choice, data structure, module interface |
| Type 3: Low Impact & Reversible | Yes, easily | Just do it, iterate based on results | Variable names, comment style, file organization |
Avoid analysis paralysis: Don't treat Type 3 decisions like Type 1. Perfect is the enemy of good enough. Make the call, move forward, adjust if wrong.
Troubleshooting Checklist
Systematic debugging: When things break, don't randomly change variables hoping for improvement. Follow a systematic process.
5-Step Troubleshooting Process
- 1. Reproduce the problem: Can you make it fail consistently? If not, you can't verify a fix.
- 2. Isolate variables: Change one thing at a time. Which component/condition causes failure?
- 3. Form hypothesis: Based on evidence, what's the most likely cause?
- 4. Test hypothesis: Make targeted change. Does it fix the problem? Why or why not?
- 5. Root cause analysis: Don't just fix symptoms. Why did this happen? How do we prevent it?
Common Debug Mistakes
Don't Do This
- Change multiple things at once
- "Try this" without understanding why
- Fix symptoms, not root cause
- Assume "it works on my machine" is sufficient
- Skip documentation of fix
Do This Instead
- Change one variable, observe result
- Form hypothesis before testing
- Understand mechanism of failure
- Test in target environment
- Document problem, cause, and solution
Quick Formulas & Conversions
Power & Electrical
| Formula | Use Case |
|---|---|
P = V × I |
Power (Watts) = Voltage × Current |
V = I × R |
Ohm's Law: Voltage = Current × Resistance |
Energy (Wh) = Power (W) × Time (h) |
Battery capacity calculations |
dB = 10 × log₁₀(P₁/P₂) |
Power ratio in decibels |
Data Rate & Bandwidth
| Conversion | Value |
|---|---|
| 1 Byte | 8 bits |
| 1 Kilobyte (KB) | 1,024 bytes (2¹⁰) |
| 1 Megabyte (MB) | 1,048,576 bytes (2²⁰) |
| 1 Gigabyte (GB) | 1,073,741,824 bytes (2³⁰) |
| 1 Gbps throughput | ~119 MB/s (divide by 8.4 for overhead) |
Project Kickoff Checklist
Start every project with these questions answered: If you can't answer these, you're not ready to begin.
Problem Definition
- What problem are we solving?
- Who is the end user?
- What does success look like?
- What happens if we fail?
- Why is this important now?
Requirements & Scope
- Do we have written requirements?
- Are they testable and measurable?
- Who approves changes to scope?
- What's in scope vs out of scope?
- What are the acceptance criteria?
Constraints & Resources
- What's the budget?
- What's the timeline?
- Who's on the team?
- What tools/infrastructure do we have?
- What are the technical constraints?
Risks & Dependencies
- What could go wrong?
- What are we assuming?
- What do we depend on externally?
- Where's the technical risk?
- How do we mitigate top risks?
Code Review Checklist
What to look for in reviews: Code reviews aren't about finding typos—they're about catching logic errors, design flaws, and maintainability issues.
Correctness
- Does it meet the requirement?
- Are edge cases handled?
- Error handling present and correct?
- Resource leaks (memory, file handles)?
- Thread safety if multi-threaded?
Design & Maintainability
- Is the approach reasonable?
- Code readable and well-structured?
- Comments explain "why" not "what"?
- Avoid premature optimization?
- Consistent with codebase style?
Testing & Documentation
- Are there unit tests?
- Do tests cover edge cases?
- Is the API documented?
- Are assumptions stated?
- Does it impact other modules?
Common Sense Checks
Sanity Test Your Results
Before accepting any calculation, measurement, or result—ask: Does this make sense?
Examples of Sanity Checks
- Power consumption: 50W for a microcontroller? Check your math. Should be milliwatts.
- Data rate: 10 Gbps over USB 2.0? Impossible. Max is 480 Mbps.
- Temperature: Sensor reading 300°C in room temperature? Calibration issue.
- Timing: Boot time 0.003 seconds? Measurement error or wrong units.
- Cost: Component costs $0.05? Is that per 1000 units? Check MOQ.
- Distance: Signal propagation 500ms over 10m cable? Speed of light says no.
Order of magnitude checks: If your answer is off by 10x or 100x, something's wrong. Always verify units, conversions, and assumptions before trusting results.
Useful Acronyms & Terms
| Acronym | Meaning | Context |
|---|---|---|
| COTS | Commercial Off-The-Shelf | Buy instead of build |
| NRE | Non-Recurring Engineering | One-time design/development cost |
| MTBF | Mean Time Between Failures | Reliability metric |
| RTM | Requirements Traceability Matrix | Requirements to tests mapping |
| PDR | Preliminary Design Review | Review system architecture |
| CDR | Critical Design Review | Review detailed design before build |
| TRR | Test Readiness Review | Ready for formal testing? |
| ConOps | Concept of Operations | How system will be used |
| ICD | Interface Control Document | Defines interfaces between systems |