When two reasonable engineers reach opposite conclusions, the right answer is a trade study with weighted criteria, scored honestly, and a written rationale you can defend a year later when someone asks why. Louder argument is the alternative, and it loses.
Two senior engineers, one whiteboard, forty minutes. One of them has flown VxWorks on three programs and would like to fly it on a fourth. The other has read the licensing quote and would like to keep the money. They are both right, they both know it, and the meeting is going nowhere, because they are arguing about operating systems when the actual disagreement is about something neither of them has said out loud: how much is heritage worth, in dollars, on this program? Put that number on the whiteboard and the meeting ends in ten minutes. Leave it off and the meeting is still going next quarter.
A trade study is a structured comparison of alternatives against criteria that were agreed before anyone scored anything. The output is a decision and the written reasoning behind it: which options were considered, what mattered and how much, how each option fared, and how confident the team is that the winner would still win if the weights shifted a little. It moves the argument from the options to the criteria, which is where the real disagreement usually lives.
The honest caveat. The math is only as honest as the weights and scores that feed it, and a study can be rigged by anyone who has decided on the answer in advance. The safeguards are all procedural: criteria and weights fixed before scoring, scores backed by evidence rather than preference, and a sensitivity check that reveals how close the call really was. A study that passes those three is defensible. One that skips them is a slide with arithmetic on it.#
It exists to make the decision defensible and the reasoning portable, so the person who asks “why did we choose this?” next year gets an answer instead of a shrug. When the result is a near-tie, that is a finding too: it says the decision hinges on something the criteria did not capture, and the honest move is to write that down rather than pretend the arithmetic settled it.
Argue about the weights, in writing, before anyone argues about the options.
The whole method fits on one page, and the order matters. Each step is cheap; skipping any of them is how a study becomes a rationalization.
Write the decision in one sentence, and name the gates. “Which RTOS runs the flight computer?” Then list the must-haves that are pass-or-fail rather than scored: a required certification, a hard cost ceiling, a link that has to close. An option that fails a gate is out before scoring starts. Gates keep a strong score in one column from dragging an unacceptable option across the line.
Choose four to seven criteria that trace to requirements. Each criterion should point at a requirement or a stated customer priority, and each should be something you can score from evidence. “Elegance” is a feeling; “engineer-weeks to first working build” is a criterion. Fewer than four and the study is a coin flip; more than seven and the weights stop meaning anything.
Weight the criteria before anyone scores. Weights are the customer’s priorities written as numbers that sum to 100. When a room cannot agree, compare the criteria two at a time, “is heritage worth more than cost?”, and count how often each one wins; the counts become the weights. Lock them. A weight that moves after the scores come in is the signature of a rigged study.
Anchor the scoring scale. Decide what a 10 and a 1 mean for every criterion before scoring, in writing: “10 means flight-proven on three programs in this class; 1 means no field history.” Anchors turn opinions into comparisons against a stated reference.
Score with evidence. Every score cites something: a datasheet, a benchmark, a quote, a measured result from a spike. Where possible, the engineer who champions an option is the one who scores its rivals, which keeps everyone honest in both directions.
Compute, then run the sensitivity check. Multiply, sum, rank. Then move each weight up and down by ten points, taking the difference from its neighbor, and watch the ranking. If the winner survives every shift, the decision is robust. If it flips on a small one, the study has found the real question, and that question goes to the customer.
Write the decision record. One page: the decision, the options, the criteria and weights, the scores with their evidence, the sensitivity result, the decision and its rationale, and what would change your mind. The record is the deliverable. The spreadsheet is its appendix.
The decision: which RTOS runs a flight computer with a three-year support window, a cost-conscious program, and a team whose experience is mostly Linux. The gates: deterministic scheduling and memory protection, which all three candidates clear. The criteria and weights were fixed before scoring; the scores are on a 1-to-10 anchored scale.
Criterion (weight)
VxWorks
Zephyr
Bare metal
Performance (25)
8 (2.00)
9 (2.25)
10 (2.50)
Cost (20)
3 (0.60)
10 (2.00)
10 (2.00)
Heritage and risk (30)
10 (3.00)
6 (1.80)
4 (1.20)
Development time (15)
9 (1.35)
8 (1.20)
3 (0.45)
Maintainability (10)
8 (0.80)
9 (0.90)
4 (0.40)
Weighted total
7.75
8.15
6.55
The result. Zephyr leads by 0.4 points. Bare metal is eliminated by development time and maintainability despite the best raw performance; that is the weights doing their job, since the program valued schedule over the last few percent of speed.#
The sensitivity check as a chart. Each bar moves ten weight points from one criterion to another and shows what happens to Zephyr’s lead. Any bar that crosses zero is a shift that flips the winner, and most of them do.
The sensitivity check. Move ten points from cost to heritage, so heritage weighs 40 and cost weighs 10. VxWorks becomes 8.45 and Zephyr becomes 7.75: the ranking flips. Try the other shifts and a pattern appears: nearly any ten points moved away from cost, or toward heritage, puts VxWorks ahead, and Zephyr only survives the shifts that leave both of those weights alone. The 0.4-point lead is fragile, and the study is honest enough to say so. Its real finding is a question rather than an answer: how much does this program value cost relative to heritage? That question is cheap to ask and expensive to guess, and the record says exactly who answered it and when.#
A gap of a few tenths between the top two options is inside the noise of any 1-to-10 scoring. Treat it as a tie, say so in the record, and decide on the factors the criteria could not capture: which option fails more gracefully, which the team can debug at 2 a.m., which keeps a second path open. Those reasons are legitimate. Hiding them behind a 0.4-point margin is the only illegitimate move.
A trade study that always agrees with the person who built it has measured the person, not the options.
Gates first, weights locked before scoring, evidence behind every score, and a sensitivity shift to find out whether the winner is real.
The most valuable output of a trade study is a page that a stranger can read in five minutes a year from now. Keep it short, keep it in version control next to the design, and keep the format the same across the project so people know where to look. The headings below are the whole template.
Decision record: one page, in this order
Decision
One sentence. “The flight computer runs Zephyr.”
Date and owner
When it was made and who is accountable for it.
Context
The requirement or constraint that forced the choice, in two or three sentences.
Gates
The pass-or-fail must-haves, and which options they eliminated.
Options
Everything seriously considered, including the ones that lost, each with a line on why it was a candidate.
Criteria and weights
The scored criteria, their weights, and what each one traces to.
Scores and evidence
The table, with a citation for every score: the datasheet, the benchmark, the spike result.
Sensitivity
Which weight shifts change the winner, and the question that exposes.
Rationale
Why this option, including any unscored factors that settled a near-tie.
What would change our mind
The future fact that would reopen the decision: a price change, a failed spike, a new requirement.
The last heading is the one most teams skip and the one that pays most. A decision with a stated reopening condition gets revisited for a reason instead of a mood, and it stays closed when nothing has changed. That is how a team avoids relitigating the RTOS choice in every hallway for two years.
One page, same headings every time, and always the last one: what would change our mind.
Default to buying it. Custom engineering is expensive, risky, and slow, and every custom component is a potential failure mode and a maintenance burden for as long as the product lives. Commercial off-the-shelf parts come with someone else’s test history, someone else’s support line, and a price that already includes their learning curve. The question is rarely “can we build it?” The question is “should we?”#
Build it when no COTS solution exists, when the requirements are unique or extreme enough that nothing on the market meets them, when the lifecycle cost of the COTS part exceeds the cost of designing your own, when a performance, size, or power target cannot be met any other way, or when the component is the core intellectual property that makes the product worth buying. Buy it when the component is outside your differentiation, when mature technology exists, when development time is short, when long-term support is available, and when the purchase price is lower than the engineering you would otherwise spend.
The build-or-buy question usually has a number in it, and the number is worth computing before the meeting instead of during it. Non-recurring engineering, the one-time cost of the design, prototyping, and qualification work, is traded against the recurring saving per unit.
Total cost against units built. The bought part starts at zero and climbs at $200 a unit; the custom part starts at $50,000 and climbs at $80. The lines cross near 417 units, and the shaded region is where custom pays.
Example: a custom power supply
COTS option: $200 per unit, available now, proven, with vendor support. One hundred units cost $20,000.#
Custom option: $50,000 of NRE for design and prototyping, $80 per unit at a quantity of 100, six months of development, and the maintenance burden stays with you. One hundred units cost $50,000 plus $8,000, or $58,000.#
Break-even: the custom part saves $120 per unit, so NRE is recovered at $50,000 / $120, about 417 units. Below that, buy. Above it, the custom part starts paying for itself, and the questions become whether the market will take 417 units, whether a six-month delay is survivable, and who supports the design for the next decade.#
The arithmetic is the easy half. The hard half is the three questions at the end of the example, because they are about the business rather than the part, and because the honest answer to “will we sell 417?” is usually “we hope so.” A trade study that puts the hope in writing has already done its job.
Buy by default, build when the need is unique or the volume clears break-even, and write the volume assumption down where it can be checked.
Every piece of software serves someone, and in an embedded system it usually serves two. The first is the person at the console, who sends a command and would like a response before the coffee gets cold. The second is the hardware: an analog front end, a DAC, a sample clock that ticks whether or not the software is ready for it. The person is patient and forgiving. The hardware is neither. Most of the time the software can serve both without anyone noticing a conflict. The design question is what happens on the tick when it cannot.
The software in the middle. The user can wait a little and forgives a lot. The sample clock on the right can do neither. Decide before the first line of code which one wins a collision.
A waveform codebase I took over was full of runtime assertions: good, careful pre- and post-condition checks, written by people who had been taught that failing fast is a virtue. In an application it is. Here, an assertion that failed stopped the binary cold, and stopping the binary meant the DAC kept clocking out whatever was left in its buffer while the power amplifiers stayed keyed. The result was wideband spurs and an emission that walked outside the mask, which is the kind of failure a regulator writes letters about. A teammate proposed documenting the contracts more thoroughly so the assertions would never trip. That was an academic fix for a physical problem.
The lesson. The one absolute in that system was getting samples to the DAC. Everything else, including the software’s own sense of correctness, came second. Pre- and post-conditions were fine; they had to be worded so that failing was never an option, and the code had to be rugged enough to survive a fault rather than tidy enough to die from one.
The rule that falls out of the story: decide, in the design, which master wins a tie, and write the decision where everyone will see it. When the hardware wins, the software is built to degrade rather than halt, to keep the sample stream flowing while it logs the fault and recovers. When the user wins, which is the right call for a great many systems, the software is free to stop and say so. The failure is building one kind while believing you are building the other.
The two masters are also two mindsets, and most engineers were raised in one of them. The application mindset assumes memory and CPU are elastic, gives every concern its own thread, considers a thing done when it has worked once, and takes the user as the master. The hardware mindset budgets every byte and cycle, puts one job on one characterized core, considers a thing done when it has been proven over a scope of conditions, and takes the sample clock as the master. Each is excellent in its own room and does terrible work in the other one. I have watched a seasoned embedded engineer debug a desktop application by blocking its user interface thread until the screen froze, where a delegate was the obvious answer, and I have watched application developers pile abstraction on a real-time path until the mutexes throttled the throughput the hardware was waiting on.
Two mindsets, side by side. Both are right at home and wrong next door. The skill is noticing which room you are standing in.
The gap is symmetric, and that is the useful part: it is nobody’s fault and everybody’s job. The engineer who can move between the rooms is rare and valuable. The team that knows the gap exists can at least ask, at the start of a task, which room this one belongs to, and staff it accordingly.
Decide in the design whether the user or the sample clock wins a collision, and know which mindset the task in front of you belongs to.
Innovation means finding better solutions. Being different for its own sake is a different activity with worse returns. The discipline is to question conventional approaches and then validate the alternative with analysis before committing to it.
Example: a gigabit data pipe
Conventional: “Use gigabit Ethernet; it is standard.”#
First principles: what are we solving? The need is 1 Gbps of throughput at low latency, on a processor with little CPU to spare for protocol overhead.#
Alternative: pipeline three USB 2.0 interfaces, 480 Mbps each for 1.44 Gbps raw, with simpler framing than TCP/IP, lower CPU overhead, and well-supported drivers.#
Evaluation: prototype both. Measure CPU utilization, latency, and complexity. Choose on data.#
Innovate when conventional solutions miss the constraints and you can prototype quickly. Use standard approaches when proven solutions exist and risk tolerance is low. Either way, the alternative earns its place through a measurement, and the measurement goes in the decision record.
An unconventional design earns its place with a measurement, never with its novelty.
The most expensive form of complexity is the kind nobody chose. It arrived because the previous project did things this way, the templates were copied, the architecture was reused, the assumption was that what worked there must work here. By the time anyone asks why, the team is six months in and the cost of unwinding it is higher than the cost of finishing it badly.
Does this complexity exist because of this problem, or because of a different problem we worked on before? If you cannot answer the first version, you are inheriting solutions that were designed for someone else’s constraints.
Inherited complexity is hard to spot from inside the team living with it. Everyone is working in good faith. The architecture has its own internal logic, and the people maintaining it can explain how it works in detail. What they often cannot explain is why it exists in this shape, beyond “that is how it has always been done.” That answer is a flag.
A team needed to get serial data from a sensor to a flight computer. The data rate was 1200 baud, about as low as digital communication gets, an interface a bored undergraduate could implement on a microcontroller in an afternoon. What the team built instead was a separate debug board with a custom high-speed bus, a custom protocol layered on top of that bus, and custom FPGA images on both ends to run the protocol. To move 1200 baud.
When asked why, the answer was: “that is what the previous project did.” The previous project had moved high-bandwidth radar data, and the architecture made sense there. This project moved one number per second, every second, and the architecture became a multi-year overrun waiting to happen. By the time anyone questioned it, year three was approaching with no end in sight, and the cost of unwinding the inheritance was higher than the cost of pushing through.
The lesson. Inherited architecture is the most expensive form of complexity, because nobody questions it. The first-principles question, “what does this problem actually require?”, has to be asked at the beginning of every project, even when the previous project’s architecture is sitting right there waiting to be copied. Especially then. The previous project solved a different problem.
The previous project is always available for copying, and it is always solving the previous problem.
Ask what this problem requires before adopting what the last one built, because inherited architecture is the complexity nobody will ever question.
One specific class of inherited complexity comes from how teams react to long lead times. The reasoning sounds responsible: this part has a 40-week lead time, we need to lock the design now to avoid a slip. The team commits to an architecture built around a specific component, accepts the complexity that part imposes, and works around it for the next two years.
The first-principles version of the same situation: lead times are an engineering input, like a mass limit or a temperature range. If a part has a 40-week lead time, that fact is data. The right response is to ask whether there is a simpler design built around parts without that lead time, before locking in the long-lead part out of fear of the slip.
Lead times, regulatory requirements, environmental specs, available expertise: all of these are inputs you design around. Every constraint that looks like an obstacle is also a forcing function. It filters out the architectures that will fail on contact with reality and points toward the ones that will survive it.
The way this fails: a team commits to a long-lead, high-complexity part early, then designs the rest of the system around the constraints that part imposes. By the time the part arrives, the architecture has fossilized around it. If the part turns out to have problems, and complex parts often do, the team is committed to working around them rather than choosing a simpler alternative that was always available. The original decision was framed as risk management. It was actually risk concentration.
The way this succeeds: when you see a long lead time, treat it as a signal to revisit the architecture. Is there a path that uses parts you can buy this week? If yes, that path is almost always cheaper, faster, and less risky than the long-lead path, even if it looks slightly worse on paper.
A 40-week lead time is data, and the first thing to do with it is look for the design that needs parts you can buy this week.
The sentinel’s project summary named three ways to get an alert out of the forest and picked one, with another held in reserve. Here is the study behind that paragraph, run by the seven steps above. It is also a demonstration of what a near-tie looks like and what to do about it.
The sentinel
How does an alert get from a node to the base station?#
Gates. Three, each traced to a requirement. The link must close with 15 dB of fade margin on every path, from the link budget. The node must stay under the $40 bill-of-materials ceiling in SR-005. The radio must operate license-free.#
A, direct at 915 MHz. Every node talks straight to the post. Simplest firmware, one radio module.
B, mesh at 915 MHz to a high gateway. Nodes relay for each other; a gateway on a tower forwards to the post.
C, direct at 433 MHz. Same star topology as A, on a band that loses less to foliage, with a larger antenna.
Gate check. Option A is 5.7 dB short after the fade allowance and is eliminated before scoring. Options B and C both close; C by about 9 dB on the worst path, B by about 16. All three pass cost and licensing.#
Criteria and weights, fixed before scoring, each traced to a requirement: node energy (30 points, SR-002), coverage of the far corners without extra hardware (20, SR-007), simplicity and development risk (25, the research phase has a clock on it), node cost (15, SR-005), and antenna size as it affects installation (10, SR-006).
Criterion (weight)
Anchors
B, mesh 915
C, direct 433
Node energy (30)
10: no relay duty; 1: continuous receive
6 (1.80)
8 (2.40)
Coverage (20)
10: any corner reachable by adding nodes; 1: dead zones need towers
9 (1.80)
5 (1.00)
Simplicity and risk (25)
10: star network, stock firmware; 1: custom routing to invent
5 (1.25)
8 (2.00)
Node cost (15)
10: one stock module; 1: two radios
8 (1.20)
8 (1.20)
Antenna and install (10)
10: whip under 10 cm; 1: a pole
8 (0.80)
5 (0.50)
Weighted total
6.85
7.10
The result is a quarter of a point in favor of the direct 433 MHz link, which is a tie. The sensitivity check says so plainly: shift ten points from simplicity to coverage and the mesh leads 7.25 to 6.80; shift ten from energy to simplicity and the direct link pulls further ahead. The scored criteria cannot settle this one, and the record says that in its own words.
Rationale. Two unscored facts decided it. First, the mesh fails gracefully: when one hop is lost, an alert reroutes, while a thin direct link fails all at once on the wettest night of the year, which is the night that matters. Second, the single number the study is most sensitive to, excess loss under canopy at each band, is a guess until someone walks the link, and it is cheap to measure both bands in the same week. So the decision is the mesh at 915 MHz, with the 433 MHz direct link held in reserve, and the research phase measures the number that would flip it.#
What would change our mind. A measured canopy loss at 433 MHz that gives the direct link 15 dB of margin on the worst path reopens the decision in favor of C, because the simpler network is worth having if the physics allows it.#
Notice what the study did and did not do. It never produced a number that made the decision for the team. It produced the gate that eliminated option A on physics, the near-tie that showed the scored criteria were insufficient, the sensitivity that pointed at the one measurement worth making, and a one-page record of the reasoning. That is a trade study working exactly as intended.
Take the last design decision your team argued about and write the gates. Check whether any option that is currently in the running fails one.
Write the criteria and weights on a whiteboard with the scores hidden. Get the room to agree on the weights first, then uncover the scores. Note which weight people wanted to change after seeing the result.
Run the ten-point sensitivity shift on an existing study. If the winner flips, write down the question it exposes and take it to whoever owns the answer.
The sentinel study produced a gate, a tie, a measurement worth making, and one page of reasoning, which is exactly what a trade study is for.
This chapter on one page
Each line is the sentence to remember from its section. The number takes you back to it.
4.1Argue about the weights, in writing, before anyone argues about the options.
4.2Gates first, weights locked before scoring, evidence behind every score, and a sensitivity shift to find out whether the winner is real.
4.3One page, same headings every time, and always the last one: what would change our mind.
4.4Buy by default, build when the need is unique or the volume clears break-even, and write the volume assumption down where it can be checked.
4.5Decide in the design whether the user or the sample clock wins a collision, and know which mindset the task in front of you belongs to.
4.6An unconventional design earns its place with a measurement, never with its novelty.
4.7Ask what this problem requires before adopting what the last one built, because inherited architecture is the complexity nobody will ever question.
4.8A 40-week lead time is data, and the first thing to do with it is look for the design that needs parts you can buy this week.
4.9The sentinel study produced a gate, a tie, a measurement worth making, and one page of reasoning, which is exactly what a trade study is for.