From Wavelet Solutions · Free, no signup
A working engineer’s guide to the discipline behind systems that ship on time and survive contact with reality. Written for the person who already builds things and wants to build them better — not for the person looking for a checklist to wave in a meeting.
Why this exists
Smart people, real budgets, plenty of tools — and projects still slip. The reason is rarely that someone got the math wrong. It’s that the team skipped a fundamental, accepted an unexamined assumption, or spent three months building the wrong thing because nobody wrote down what “done” meant.
This guide is the playbook I wish I’d been handed twenty years ago: the constraints you can’t engineer around, the discipline of writing requirements that hold up in court, the trade-study habits that make decisions defensible, and the integration patterns that turn the last six weeks of a project from a death march into a victory lap.
It is opinionated. It is specific. It is not a survey of the literature. It is what I would actually tell you if you walked up to my desk and asked.
The pattern you already recognize
None of these are imaginary. Each of them maps to a chapter of this guide — not because there’s a magic fix, but because there’s a discipline that, applied honestly, makes them rarer.
01 / Velocity
Everyone is busy. Nothing ships.
The change is small. The discussion about the change is enormous. There are four reviewers, three of whom don’t actually have authority, and one who’s been on PTO since the last sprint. Six weeks later, the change still isn’t in. You’re debugging process instead of product.
The fix is not “more agile” or “fewer reviewers.” It’s knowing which decisions actually require ceremony and which don’t — and being able to defend that distinction with first principles. Covered in Lifecycle and Design.
02 / Requirements
So testing is guesswork.
Two engineers stare at the same one-line bullet in a slide deck and walk away with different mental models. The QA team writes tests against one of them. The customer was thinking about the third option that nobody wrote down. Acceptance is a negotiation instead of a verification.
Requirements are contracts. They have to be testable. They have to be traceable. They have to be specific enough that two competent engineers reach the same conclusion. Covered in Requirements.
03 / Constraints
Power, mass, link, timing.
You won’t know you’re over the power budget until something browns out under load. You won’t know your timing margin is two milliseconds until a sensor latency spike eats it and a control loop oscillates. The constraints are real whether you wrote them down or not. The only question is whether you find out at design time or in the field.
Real engineers maintain budgets from day one. Margin below 20% triggers a flag. Negative margin triggers a re-architecture. Covered in Fundamentals.
04 / Integration
Every time. For everyone.
The subsystems work in isolation. The interfaces drift during development. The first time the whole thing talks to itself end-to-end is two weeks before delivery, and it doesn’t. The team blames itself for being unprepared, but the problem was structural: nobody was building integration into the schedule from day one.
The fix is to design for testability before you write any code, lock interfaces before internals, and stand up integration test points incrementally as subsystems come online. Covered in Integration and Verification.
Who this is for
You’ve learned the tools. You can write code, read a schematic, run a test. You can sense that the people around you are doing something different than you, but you can’t name it yet. That “something” is the discipline of working under constraints. This guide is what your mentor would tell you over coffee, written down so you can revisit it.
Start with Start Here, then Fundamentals.
You’ve seen projects succeed and fail. You suspect the failures had patterns. You’re right. This guide names the patterns — bad requirements, missing margins, integration as an afterthought, processes that exist for compliance rather than effect — and gives you language to push back when you see them.
Skip the intro. Open the chapter that matches your current pain.
You weren’t trained for this. You’re running a program that has technical depth, schedule pressure, and stakeholders who use words you don’t recognize. You need a vocabulary and a framework, fast. The Reference chapter is the cheat sheet. Then read the rest in any order.
Start with Reference, especially the red-flag list.
What’s in the guide
The chapters are ordered the way a project unfolds, but each one stands on its own. Open the one that matches what you’re wrestling with this week.
The shape of the problem and the philosophy of the rest. Read this first if you’ve never thought of engineering as a discipline you can name.
01Power, mass, link, timing. The four budgets that decide whether a system is physically possible. If you can’t fill these in, you don’t have a design yet.
02Requirements as contracts. Writing them so they’re testable, decomposing them so they’re tractable, tracing them so they survive the lifecycle.
03How to choose between alternatives and defend the choice. COTS versus custom. The discipline of innovation under constraints.
04Designing for testability from day one. Locking interfaces before internals. Building incrementally so the last six weeks aren’t a fire.
05Proving the system meets its requirements, not just “it seems fine.” Test strategies, traceability matrices, reliability and environmental testing.
06From concept to retirement. Phase deliverables, code freezes, hotfix discipline, and the difference between anticipating customer needs and building for hypothetical ones.
07Context diagrams, the C4 model, flowcharts, UML, and the discipline of choosing the right altitude for the question you actually have.
RefThe red flags, decision frameworks, troubleshooting checklists, and acronym glossary you’ll come back to. Bookmark this one.
Why this is free
This guide is published by Wavelet Solutions as a public resource. There is no paywall, no signup, no email harvest, no “upgrade to read the rest.” Engineering knowledge is most valuable when the people who need it can find it without negotiating with a vendor first.
If it helps you, the best return on the favor is to apply it. Build something that works. Push back on the next bad requirement you see. Mentor the engineer behind you. That’s the loop this guide is trying to feed. If you want to support it directly, that page exists too — but it’s not the point.
Ready when you are
You don’t have to start at the beginning. Open whatever’s on fire and read from there.