Introduction to Professional Practices
The difference between a hobbyist project and a professional product isn’t the circuit — it’s the process. Professional hardware engineering demands rigorous documentation, version control, structured design reviews, and formal change management. These practices prevent costly mistakes, enable team collaboration, and ensure your designs can be manufactured, maintained, and improved over years.
Evolution of Hardware Engineering Practices
Documentation Standards
| Document | Purpose | When Created | Owner |
|---|---|---|---|
| Product Requirements (PRD) | What the product must do | Concept phase | Product/Systems |
| Hardware Spec (HWS) | Detailed electrical/mechanical spec | Design phase | HW Engineer |
| Schematic & Layout | Circuit design + PCB files | Design phase | HW Engineer |
| BOM (Bill of Materials) | Component list with sources | Design phase | HW Engineer |
| Test Plan | How to validate the design | Design phase | Test Engineer |
| DVT Report | Design validation results | DVT phase | Test Engineer |
| Manufacturing Package | Everything CM needs to build | Pre-production | HW Engineer |
Project File Structure
# Standard hardware project directory structure
# Organized for Git version control + collaboration
project-name/
├── README.md # Project overview, setup instructions
├── CHANGELOG.md # Version history (follows Keep a Changelog)
├── .gitignore # Ignore generated files, caches
├── .gitattributes # LFS tracking for binary files
│
├── docs/ # Documentation
│ ├── PRD-v1.0.pdf # Product Requirements Document
│ ├── HWS-v1.0.pdf # Hardware Specification
│ ├── test-plan-v1.0.pdf # Test Plan
│ └── design-review/ # Review meeting notes
│ ├── schematic-review-2026-01-15.md
│ └── layout-review-2026-02-01.md
│
├── hardware/ # EDA project files
│ ├── kicad/ # KiCad project (or altium/)
│ │ ├── project.kicad_pro
│ │ ├── project.kicad_sch # Schematic
│ │ ├── project.kicad_pcb # PCB layout
│ │ └── libraries/ # Custom symbols + footprints
│ ├── gerbers/ # Manufacturing outputs
│ │ ├── rev-A/
│ │ └── rev-B/
│ └── bom/ # Bill of Materials
│ ├── bom-rev-A.csv
│ └── bom-rev-B.xlsx
│
├── firmware/ # Embedded firmware
│ ├── src/
│ ├── include/
│ ├── Makefile
│ └── README.md
│
├── mechanical/ # Enclosure / 3D models
│ ├── step/
│ └── drawings/
│
└── test/ # Test scripts and fixtures
├── functional/
├── fixtures/
└── reports/
Version Control for Hardware
# Git setup for hardware projects
# Use Git LFS for large binary files
# Initialize repo
git init
git lfs install
# Track binary files with LFS
git lfs track "*.kicad_pcb"
git lfs track "*.step"
git lfs track "*.pdf"
git lfs track "*.xlsx"
git lfs track "*.png"
git lfs track "*.jpg"
git lfs track "gerbers/**"
# .gitignore for KiCad projects
cat > .gitignore << 'EOF'
# KiCad generated files
*-backups/
*.kicad_pcb-bak
*.kicad_sch-bak
*.tmp
fp-info-cache
*.dsn
*.ses
# Build outputs
firmware/build/
*.o
*.elf
*.bin
*.hex
# OS files
.DS_Store
Thumbs.db
EOF
# Commit structure
git add .
git commit -m "Initial project structure — Rev A schematic complete"
Engineering Change Order (ECO) Process
flowchart TD
A["Issue
Identified"] --> B["ECO Request
Filed"]
B --> C["Impact
Analysis"]
C --> D{"Review
Board"}
D -->|Approved| E["Implement
Changes"]
D -->|Rejected| F["Document
Rationale"]
E --> G["Update
Documentation"]
G --> H["Rev Increment
A → B"]
H --> I["Verify &
Close"]
Design Review Checklist
# Schematic design review checklist generator
# Systematic review categories with pass/fail tracking
review_categories = {
"Power": [
"All power nets labeled with voltage",
"Decoupling caps on every IC VDD pin",
"Bulk capacitor on each power rail",
"Voltage regulator thermal pad connected",
"Power-on sequence documented",
"Reverse polarity protection present",
],
"MCU": [
"Reset circuit with proper RC time constant",
"Boot pins configured for normal operation",
"Crystal load caps match manufacturer spec",
"All unused pins tied to known state",
"Debug header (SWD/JTAG) accessible",
"Watchdog timer enabled in firmware",
],
"Connectivity": [
"ESD protection on all external interfaces",
"Impedance-controlled traces for high-speed signals",
"Series termination on clock outputs",
"Connector pinouts verified against mating part",
"Pull-up/down resistors on I2C/SPI buses",
],
"Mechanical": [
"Mounting holes match enclosure",
"Board outline within enclosure constraints",
"Connector placement accessible after assembly",
"Thermal vias under power components",
"Keepout zones around antenna/RF section",
],
}
print("Schematic Design Review Checklist")
print("=" * 65)
total = 0
for category, items in review_categories.items():
print(f"\n{'─' * 65}")
print(f" {category.upper()} ({len(items)} items)")
print(f"{'─' * 65}")
for i, item in enumerate(items, 1):
print(f" [ ] {i}. {item}")
total += 1
print(f"\n{'=' * 65}")
print(f" Total checklist items: {total}")
print(f" Categories: {len(review_categories)}")
print(f" Review date: ________________")
print(f" Reviewer: ________________")
print(f" Verdict: [ ] PASS [ ] PASS w/ COMMENTS [ ] FAIL")
Schematic Design Review Checklist ================================================================= ───────────────────────────────────────────────────────────────── POWER (6 items) ───────────────────────────────────────────────────────────────── [ ] 1. All power nets labeled with voltage [ ] 2. Decoupling caps on every IC VDD pin [ ] 3. Bulk capacitor on each power rail [ ] 4. Voltage regulator thermal pad connected [ ] 5. Power-on sequence documented [ ] 6. Reverse polarity protection present ───────────────────────────────────────────────────────────────── MCU (6 items) ───────────────────────────────────────────────────────────────── [ ] 1. Reset circuit with proper RC time constant [ ] 2. Boot pins configured for normal operation [ ] 3. Crystal load caps match manufacturer spec [ ] 4. All unused pins tied to known state [ ] 5. Debug header (SWD/JTAG) accessible [ ] 6. Watchdog timer enabled in firmware ───────────────────────────────────────────────────────────────── CONNECTIVITY (5 items) ───────────────────────────────────────────────────────────────── [ ] 1. ESD protection on all external interfaces [ ] 2. Impedance-controlled traces for high-speed signals [ ] 3. Series termination on clock outputs [ ] 4. Connector pinouts verified against mating part [ ] 5. Pull-up/down resistors on I2C/SPI buses ───────────────────────────────────────────────────────────────── MECHANICAL (5 items) ───────────────────────────────────────────────────────────────── [ ] 1. Mounting holes match enclosure [ ] 2. Board outline within enclosure constraints [ ] 3. Connector placement accessible after assembly [ ] 4. Thermal vias under power components [ ] 5. Keepout zones around antenna/RF section ================================================================= Total checklist items: 22 Categories: 4 Review date: ________________ Reviewer: ________________ Verdict: [ ] PASS [ ] PASS w/ COMMENTS [ ] FAIL
Mars Climate Orbiter (1999) — Documentation Failure Destroys $327M Spacecraft
NASA’s Mars Climate Orbiter was lost because one engineering team (Lockheed Martin) used Imperial units (pound-force seconds) for thruster impulse data, while NASA’s navigation team expected metric units (Newton-seconds). The spacecraft entered Mars’s atmosphere too low and disintegrated.
Root cause: The interface specification document (SIS) didn’t explicitly specify units for the thruster data. The design review process didn’t catch the discrepancy because reviewers assumed their own unit conventions. Ground software validation tests weren’t run against actual thruster data.
Lesson: Documentation must be unambiguous. Every interface specification needs explicit units, ranges, and validation criteria. Design reviews must include cross-team reviewers who challenge assumptions.
SparkFun Electronics — Open-Source Hardware and Git-Based Version Control
SparkFun, a leading open-source hardware company, transitioned from manual file management to Git-based version control for all their PCB designs in the early 2010s. With 500+ products, they needed a system that tracked every revision, enabled multiple engineers to work in parallel, and supported customer access to design files.
Implementation: All Eagle (later KiCad) files hosted on GitHub. Each product gets its own repository. Releases tagged with board revision (v10 = Rev 1.0, v11 = Rev 1.1). Manufacturing files (Gerbers, BOMs) stored as release assets. Design rules automated via CI scripts that check DRC on push.
Result: Reduced “wrong file sent to fab” errors by 95%. New engineers onboard faster with documented commit history. Customers can track exactly which revision they have and see what changed. Manufacturing package generation automated.
Lesson: Git isn’t just for software. With LFS for binary files and proper .gitignore, it’s the best version control system available for hardware teams of any size.
Project Management
ECO Tracker Tool
Engineering Change Order Tracker
Document engineering changes systematically. Download as Word, Excel, or PDF.
Practice Exercises
Exercise 1: Set Up a Hardware Project Repository
Create a Git repository for a hypothetical IoT temperature logger project. Include:
- Proper directory structure (hardware/, firmware/, docs/, test/)
- .gitignore for KiCad generated files
- .gitattributes with LFS tracking for binary files
- A README.md with project overview, setup instructions, and revision history table
- A CHANGELOG.md following “Keep a Changelog” format with one initial entry
Hint: Use the directory structure shown in the “File Structure” section above as a starting point. Track *.kicad_pcb, *.step, *.pdf, and gerbers/** with LFS. Your README should include the board dimensions, MCU selection, and power requirements.
Exercise 2: Write an ECO
Your Rev A prototype has a problem: the 3.3V LDO (AMS1117-3.3) overheats and shuts down under full sensor load (850mA). Write a complete ECO that:
- Describes the issue with measured data (junction temp, thermal shutdown threshold)
- Proposes a solution (replace with TLV1117LV33 or switch to buck converter)
- Lists all affected documents (schematic, BOM, PCB layout, test plan)
- Assesses impact on schedule, cost, and certification
- Defines verification criteria for the fix
Hint: AMS1117 dropout = 1.3V at 850mA, so Pd = 1.3×0.85 = 1.1W. With θja = 90°C/W, Tj = 25 + 99 = 124°C (thermal shutdown at 125°C). TLV1117LV33 has lower dropout (0.55V) → Pd = 0.47W → Tj = 67°C. Or a buck converter like TPS54302 drops Pd to ~0.1W.
Exercise 3: Conduct a Design Review
Using the 22-item checklist generated above, review this fictional schematic scenario and identify all issues:
- STM32F4 MCU with 8 MHz crystal — load caps are 10pF (crystal spec says CL = 20pF)
- USB connector has no ESD protection IC
- 3.3V rail has a 100µF bulk cap but no decoupling on the accelerometer IC
- SWD debug header is placed under the battery holder
- BOOT0 pin is floating (no pull-down resistor)
For each issue, state which checklist item it violates, the risk level (critical/major/minor), and the fix.
Hint: Crystal load caps: CL = 20pF, stray ~3pF, so each cap = 2×(20-3) = 34pF (not 10pF) — MCU item #3. USB ESD: Connectivity item #1 — add USBLC6-2. Missing decoupling: Power item #2. SWD inaccessible: Mechanical item #3. BOOT0 floating: MCU item #4 — add 10kΩ to GND.
Conclusion & Next Steps
Professional practices separate hobbyist projects from production-ready hardware. Structured documentation, version control, systematic design reviews, and a formal ECO process ensure that your designs are reproducible, maintainable, and ready for team collaboration.
Next in the Series
In Part 16: System-Level Design, we’ll tackle enclosure engineering, thermal management, cable/connector selection, and user experience considerations for complete embedded products.