The Engineering Principle: If You Don't Know What You're Doing, Don't Do It

The “engineering principle” is attributed to Richard Hamming, a legendary mathematician and computer scientist at Bell Labs.

He contrasted the mindset of research versus engineering with this specific distinction:

In science: if you know what you’re doing, you should not be doing it.
In engineering: if you do not know what you’re doing, you should not be doing it.”

This simple formulation captures a fundamental difference between exploratory research (where the destination is unknown) and engineering application (where a destination has been chosen and the focus is now on delivery).

I believe using this distinction can be extremely helpful in modern system design and delivery.

In the “science” phase: any project should consider the available data and analysis to decide what can, or should, be done. For me, the ideal is that this phase creates outputs that feed into subsequent engineering phases.

In the “engineering” phase: we should use the understanding gained in the “science” phase, with particular focus on:

1. Functional requirements. What should any the system actually do? How should it behave?
2. Non-functional requirements. These can include meeting constraints derived from the problem space e.g. technical, legal, financial, operational restrictions.
3. Other outputs may include documenting preferences. In some systems we may prefer low-latency over scalability; in others, we may prefer resilience over multiple geographic regions.

In large companies, these functions may be done by different people, or departments, but in smaller companies and in startups, the engineering team often have to perform both activities.

Related Quotes

While Hamming’s quote is the definitive on the “engineering principle”, many thinkers have expressed similar ideas:

The Fail-Safe Minimization Principle:

If you don’t know what you’re doing, don’t do it on a large scale.

This appears in Tom Gilb’s Principles of Software Engineering Management and is used to advocate for small, incremental testing when faced with uncertainty.

W. Edwards Deming on process:

W. Edwards Deming is highly quotable on all matters of process and quality, but I found this an interesting variation.

If you can’t describe what you are doing as a process, you don’t know what you’re doing.

The “Fit and Force” Rule:

A common workshop adage often taught as the “First Rule of Engineering” is:

If it doesn’t fit, don’t force it.

This is the physical world’s analogue to “not starting”, or continuing execution, if the parameters or other context are known to be incorrect.