| Episodes | 52 |
| Mentions | 82 |
| Cited here | 33 |
| First — last | #17 — #718 |
| Top guests | Charles Aylward, Jeff Keyzer, Pallav Aggarwal |
| Related | schematic · pcb layout · altium · datasheet · firmware |
A design review is a structured examination of an engineering design by people other than, or in addition to, its original designer, conducted to find defects, challenge assumptions, and transfer knowledge before the design is committed to fabrication or production.[211][287] The practice rests on a documented limitation of self-checking: a designer reviewing their own work tends to skip over elements they are certain are correct and to see things that exist only in their head rather than on the page, so even a formal checklist performs better when someone else runs it.[287] Beyond defect detection, a rigorous review serves a second function as a teaching mechanism, instructing engineers in how to design, test, evaluate, and document, and organisations that treat it purely as quality control extract less value from it than they could.[138]
Rationale
Self-review does not converge on the defect that matters: an engineer can return to their own work repeatedly and still not catch the thing that will cause the problem.[492] The structural consequence falls hardest on the sole engineer at a small company, who has no review in either direction, whereas a contractor placed inside an existing team receives it as a matter of course; the absence is a structural risk rather than a failure of individual diligence.[492] The reviewer need not out-rank the designer technically — a fresh set of eyes is frequently sufficient on its own to unstick a stalled design.[425] Circulating a board for checking before fabrication is worthwhile even when the reviewers are less experienced than the designer, because enthusiasm produces methodical component-by-component checking that an expert tends to skim past.[201]
The value of review compounds with perspective rather than headcount: two engineers working as a team are worth three working separately, because the gain is someone with a different perspective challenging how the requirement or standard was interpreted, not additional hours.[588] Review is also the mechanism by which experience becomes skill rather than repetition — an hour of work followed by a colleague identifying what is wrong with it counts as practice, while an hour of unreviewed work does not, because practice only compounds where feedback closes the loop.[140]
Conduct of a review
The working form of a review is adversarial but evidenced: the reviewer states that something will not work and gives the reason, and the designer defends the design technically by producing data; a company where that exchange is expected is functioning as intended.[211] An objection must carry its reason with it, because saying only that something will not work gives the designer nothing to answer and converts a technical disagreement into a personal one.[116]
Preparation determines what a review can accomplish. Readable schematics circulated on paper before the meeting are necessary, because asking a room to navigate to a page of a PDF does not work and reviewers must be able to mark up and cross-reference pages simultaneously.[116] The designer should arrive with evidence rather than conclusions — datasheets, test reports, and everything generated during the design — since the reviewers’ questions will range across whatever they know, and material that cannot be produced in the room becomes the open item.[138] A review of someone else’s design begins before the schematic, with existing documentation, any competitive analysis, and the reason the thing is being built at all; without the intent, a reviewer can check consistency but not suitability.[321]
Timing matters as much as content. Interrupting a designer mid-schematic with alternatives already tried and rejected is corrosive, because the designer must then prove a negative; presenting a finished holistic view and defending it is the exchange that works.[122] Cost is a standing participant in the review of any high-volume product: the component that would obviously improve the design is frequently one the bill of materials cannot carry, and that constraint is not a failure of engineering ambition.[96]
Reviewing one’s own work should be treated as impossible and the checking arranged for someone else, a habit worth keeping even on designs simple enough that the error seems unlikely.[174] Since almost nobody enjoys being reviewed, the durable approach is to enter each review intending to learn at least one thing, which makes the time productive regardless of how the design fares.[138]
Relationship to automated checking
A review answers a different question from a rule check. Automated checking asks whether something can be done; a reviewer asks whether it should be — an ESD protection diode that solves one problem while creating three others is the kind of decision no rule set flags.[505] Rules of thumb earn their place in the review room because, with ten people around a design on the wall, the question is whether the design will work or is in the danger zone, and nobody is going to run a three-dimensional field solver to find out; fast approximation is what lets a group explore the design space at the whiteboard.[252]
Automation reshapes what review must cover rather than eliminating it. Substituting a passive component on its headline parameters — capacitance, package, voltage — misses parameters buried deeper in the catalogue, such as dielectric technology or tolerance, and exhaustive automated comparison removes the dependence on how thorough a reviewer happened to be that day.[577] Automatically generated schematics split along a familiar axis: generation from datasheet data covers anything but produces work requiring careful review, while assembly of manufacturer-supplied blocks known to work covers less ground with much higher assurance, leaving only the connections between blocks to be checked.[718]
Failure modes
Reviews of customer designs have repeatedly found large fractions — in one case forty percent — that could simply be deleted on cost and power grounds; the diagnostic question is why each block is present, and the revealing answer is silence.[661] A domestic appliance failed after ten years because its designers ran resistors far too hot, a mistake a five-minute review would have caught, with the cost landing on the owner as a heavy, expensive product scrapped for a component worth cents.[628] Insufficient scrutiny tends to surface first in mechanical safety rather than electronics: a multi-pound spinning disc retained by a single grub screw on a motor shaft is the kind of decision that survives only because nobody senior looked at it.[135]
When a product fails on something as calculable as write endurance, only two explanations remain — nobody ran the numbers, or somebody did and was unwilling to say so — and both are review-culture failures rather than technical ones, the second being the more serious.[464] Schedule pressure on a first custom board strips out testability first — no test points, no broken-out debug channel — producing a board that yields no information when it fails to boot, and the time saved by not fanning out a test interface is reliably smaller than the time then spent guessing.[584] Skipping design work up front produces visible early progress and an unverifiable result: work written to get something running quickly becomes tangled enough to be thrown out and restarted, the apparent speed repaid with interest.[35]
Reviews themselves can fail. Engineers are sometimes required to defend a design they did not choose and do not believe in, and the predictable result is that the specification or the results get massaged, converting the review into theatre.[116] Having one’s reasoning heard, considered, and overruled is a legitimate outcome; being ignored and told not to rock the boat is a different thing, reasonably read as information about the employer rather than the design.[256]
Economics and organisational context
Process rigour has acquired a poor reputation next to lighter-weight methods, but it makes a project faster overall — slower at the start, with a crossover point after which the accumulated rework of the fast approach exceeds it.[584] First-time-right designs are the visible end of front-loaded work, months of evaluation and repeated review, rather than evidence of a better designer; a claim of first-time-right without that investment describes a small delta revision, not a new design.[661] The time spent checking before fabrication is the cheapest time in the project, and the correct expectation is that something will be wrong regardless — checking changes how much, not whether.[17]
Some organisations staff a second team purely to look over the shoulders of the first, formally and informally, as a standing culture of peer review; it works, and it is contentious, because professional rivalries do not disappear merely because the process is professional.[119] A standing meeting of fifteen to twenty specialists discussing problems in their own domain is an unmatched teaching environment, and it is what an engineer entering a small company gives up without necessarily realising it.[573] Outside a structured organisation the guardrails must be built deliberately: mentorship has to be sought out and design reviews have to be paid for, a real cost that people leaving structured employers routinely fail to budget; buying a third-party review is a reasonable substitute where a team is too small to hold one internally.[588][584] Internal peer review also filters invention disclosures before they reach a patent attorney — a design community says either that the idea was done a decade ago or that it has legs, far cheaper than learning the answer from a patent examiner.[270] Designing where others can watch the process rather than only the result improves quality directly, because knowing the work is visible changes how carefully it is done and makes a team more receptive to feedback than designing in a vacuum does.[525]
Collaborative and tooling models
A workable model for collaborative hardware development is one designer making substantial changes with two or three others acting as sounding board, reviewer, and architecture help; it depends on the design tool using a text-based file format, because otherwise revision control cannot support the conversation.[161] The pull request is the software world’s design review — a branch carrying proposed changes, opened for comment before it merges — and bringing that pattern to hardware requires only tooling that can show what changed between two versions.[505] A reviewer from an adjacent discipline catches a distinct class of error: a firmware engineer reviewing a schematic sees the consequences of pin assignment and boot configuration that the hardware designer has stopped noticing.[504]
Design for reviewability
A schematic that flows left to right, with well-named components and notes describing intent, is reviewable in a way that a hundred-page binder with one net per page is not; good architecture documents itself to a degree, and the point at which a design stops being self-explanatory is usually the point at which it was bent to do something it was not designed for.[365] Handing over the reasoning, not just the design — which constraints applied, why a circuit looks odd, and honestly which parts the designer would do differently — lets the next engineer build on the work instead of rediscovering the same dead ends, and is more useful than any volume of after-the-fact documentation.[365] One question added to the review agenda — when this board comes back and does not work, how will we find out why — is what puts test points on the board when it is answered before fabrication.[584]
Reviews in silicon development
On compressed silicon schedules, board work begins before the pinout is finalised, with layout and applications engineers engaged from the outset and schematic capture proceeding in parallel with tape-out; schematic and layout reviews still happen, but against a moving target.[452] Bringing up untested silicon usually requires a custom socket so parts can be swapped, and those sockets run into thousands of dollars — a cost that belongs in the schedule discussion early, because the test programme cannot be validated without physical samples.[452]