Every shop has tried to fix engineering documentation the same way. A part comes back with a question nobody can answer, someone spends two days digging, and the lesson is always the same: we need to document better. So there's a new template, a reminder in the Monday meeting, a push that lasts a few weeks. Then the next question comes back, and nobody can answer it either.
If that sounds familiar, here's the part nobody says out loud. The problem was never the effort. It was the process and the tooling.
The frustration nobody names
You know the feeling even if you've never had a word for it. A customer asks for a variant of a job you did three years ago. A supplier asks why a note is on the drawing. Someone wants to "simplify" a feature, and nobody is sure whether it was there for a reason.
So you dig. Old email, the shared drive, a binder on the shelf, a call to the person who did the job, if they still work here. Sometimes you find it. Often you rebuild the reason from scratch: re-run the test, redo the calc, ask the same questions the team asked last time.
That's the cost. Not the time spent writing documents, but the time spent paying twice for work your shop already did once. It doesn't show up on any report, so it rarely gets called what it is.
What CAD fixed, and what it didn't
Engineering has made a jump like this before. For decades, every line on a drawing was made by hand on a board with pencils, triangles and an eraser shield. When CAD arrived, it didn't change how shops worked at first. A history of mechanical design from Johns Hopkins APL puts it plainly: for nearly 30 years, CAD tools "merely digitized these drawings" (Crane, JHU APL Technical Digest). Architect and MIT professor William Mitchell described early CAD the same way: efficient substitutes for hand drafting "within otherwise very traditional design and documentation processes" (Mitchell, 2006).
CAD was still a huge win. Revisions got faster, drawings got cleaner, one station replaced a room of boards. But be honest about what it moved. CAD digitized the drawing. It didn't digitize the knowing: why the wall is that thick, why that material, why the fit test was redone. That stayed where it always was, in people's heads, in email threads and in binders.
Why engineering documentation fails even in good shops
It isn't laziness. Look at what we ask people to do.
- Documentation is a second job. The work happens in CAD, on the floor and in conversations. Writing it down happens later, in a different place, when the deadline has already moved on. Researchers who studied design rationale capture heard the same thing from experts: the people producing the record "have to benefit themselves," or it doesn't get done (Design Society).
- The reason lives far from the change. The drawing shows what changed. The why sits in an email, a test report, a meeting nobody wrote up.
- Finding it is the real bottleneck. Plenty of shops have more documents than anyone reads. Engineers on forums describe stacks of reports that nobody opens, and the same failure coming back years later because the person who knew had left.
None of that gets fixed by trying harder. It gets fixed by changing where the reason lives and how you get it back.
Software teams already work this way
Software developers had the same problem: code says what it does, rarely why. What changed for them in the last few years is the tooling, not the willpower.
Most developers now work with an AI assistant built into the editor. It reads the code around the cursor, the rest of the file and the project, and suggests the next change right where they're working. The developer sees the change, then accepts it or keeps typing. In the 2025 Stack Overflow survey, 84% of respondents said they use or plan to use AI tools in development, and 51% of professional developers use them daily (Stack Overflow, 2025). In one controlled trial, developers with an AI assistant finished a coding task 55.8% faster than those without (Peng et al., 2023).
It isn't magic, and developers don't fully trust it either. That's why the good tools show the change and leave the decision to the person. What made it work wasn't a new discipline. The assistant sits where the work already is, and it can see the context.
The same shift fits your shop, without starting over
Your shop doesn't need a new system to fill in. The reasons already exist: in the drawings, the change orders, the test reports, the emails you can export, the notes in the binder. What's been missing is a way to read across them and bring the reason back when someone asks.
That's the update a world built on drawings and binders has been waiting for. Not reinventing how you engineer, just giving the work you've already done a way to answer back. Software went first because its work was already digital. Your work is digital now too.
Try this week: the two-year test
- Pick one change from about two years ago. A dimension, a material, a supplier switch.
- Time how long it takes to find out why. Not what changed, why. Note where the answer was, or that it wasn't anywhere.
- Write one line where the change lives. On the next change you make, add "Because:" and "Source:" on the change order or the drawing note. Thirty seconds now saves the next engineer (often you) the dig.
If step 2 took more than an hour, that hour is what your shop pays every time the question comes back.
HarV connects each change to the reason behind it, from the files your team uploads, with the source one click away.
Photos: NASA Glenn Research Center (public domain); ThisIsEngineering, cottonbro studio (Pexels). Editor screenshot adapted from Visual Studio Code docs, Microsoft, CC BY 3.0 US.
Frequently asked questions
What is engineering documentation?
The record of how a product was designed, built and changed: drawings, specs, calculations, test reports, change orders and bills of materials. The most useful part, and the most often missing, is the reason behind each decision.
Why is documentation important in engineering?
Because parts come back. Variants, repairs, supplier questions and audits all depend on knowing why something is the way it is. Without it, teams redo work they already paid for.
What are engineering documentation best practices?
Keep the reason next to the change, write it while the work is fresh, record the source (test report, email, review), and make it easy to find later. One line of "because" beats a long report nobody opens.
Is manual drafting still used, or has CAD replaced it?
CAD replaced hand drafting for production drawings in most shops by the 1990s and 2000s, though many engineers still sketch by hand first. CAD changed how drawings are made; it didn't change how the reasons behind them are kept.
