WhatEngineeringIs

The Accreditation Board for Engineering and Technology (ABET, the body that accredits nearly every engineering degree programme in the United States) defines engineering as "the profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind."

Read that definition slowly and it says something more specific than "engineering uses science." A physicist can fully understand how a material bends under load without ever needing to decide how thick to make a beam, on a real budget, by a real deadline, using material that is actually available to buy. The moment "economically" and "for the benefit of mankind" enter the sentence, the discipline has shifted from understanding how something works to deciding what to actually build, and that decision is always made under constraints science alone does not resolve.

This course treats that distinction as the thing worth understanding first, before any specific technical content, because it explains why the rest of the course is organised the way it is: not around abstract physics, but around the recurring problem of turning physics into a working thing on a budget.

ABET, definition of engineering, as reproduced in engineering curriculum materials, https://users.ece.utexas.edu/~holmes/Teaching/EE302/Slides/UnitOne/tsld002.htm.

A common misconception, easy to hold before doing any real engineering work, is that constraints are an annoyance layered on top of "the real engineering," which is imagined as the pure technical problem underneath. In practice, identifying and satisfying constraints usually is the engineering, the technical solution to "make a beam strong enough" is often straightforward; the actual work is making it strong enough within a mass budget, a material cost, a manufacturing process and a deadline, all at once.

Constraints come from several different places, and a working engineer has to keep track of which kind each one is. Physical constraints (the yield strength of a material, the speed of light, the boiling point of water at a given pressure) cannot be negotiated at all. Regulatory constraints (a building code, a safety standard, an emissions limit) can occasionally be challenged or waived through a formal process, but are not simply optional. Resource constraints (budget, schedule, available skilled labour) are genuinely negotiable in principle, but negotiating them usually costs something else the project also needs.

Confusing these categories is a common and costly mistake. A team that treats a resource constraint as though it were a physical law gives up options it actually had; a team that treats a physical constraint as though it were merely a resource problem wastes effort trying to negotiate something that was never going to move.

A first design rarely works exactly as intended, and treating that as a failure rather than as the normal middle of the process is one of the more damaging habits a new engineer can carry. NASA’s own Systems Engineering Handbook builds this into its formal vocabulary: it defines "iterative" as the "application of a process to the same product or set of products to correct a discovered discrepancy or other variation from requirements," and "recursive" as adding value to a system "by the repeated application of processes to design next lower layer system products or to realize next upper layer end products within the system structure."

In plain terms: iteration is going back and fixing the same thing once you have learned it does not quite meet the requirement; recursion is applying the same basic design process again, one level of detail down, to design the pieces that make up the whole. A large engineered system (a spacecraft, a car, a bridge) is not designed once from the top; it is designed, checked and corrected, over and over, at every level from the whole system down to individual components, until every level satisfies its own requirements and those pieces fit together correctly.

That structure is why "engineering design process" diagrams almost always include a loop rather than a straight line from problem to solution. The loop is not a diagram of things going wrong, it is a diagram of how a design actually gets right.

NASA Systems Engineering Handbook, NPR 7123.1, definitions of "iterative" and "recursive," https://www.nasa.gov/reference/2-0-fundamentals-of-systems-engineering/.

The design process this chapter describes is common across engineering; what differs by discipline is the physics, materials and systems each one works with. ABET separately accredits programmes in civil, mechanical, electrical, chemical, industrial, aerospace, biomedical, environmental and computer engineering, among others, distinct disciplines built around distinct bodies of technical knowledge, all applying the same underlying design and constraint-management process this chapter has just described.

The distinction shows up formally, too: the National Council of Examiners for Engineering and Surveying administers separate Principles and Practice of Engineering licensing exams for different disciplines, because a professional engineer’s licensed competence in structural design does not, on its own, establish competence in electrical power systems or chemical process design, the disciplines share a process but not a body of specialised knowledge.

This course spends its remaining eight chapters moving across several of those bodies of knowledge in turn (statics and materials, thermodynamics and fluids, electrical fundamentals, control systems) precisely because a foundational engineering education is expected to give a working sense of all of them, even for a student who will eventually specialise in only one.

National Society of Professional Engineers, on ABET accreditation categories and NCEES licensing examinations, https://www.nspe.org/career-growth/pe-magazine/january-2018/revised-abet-criteria-will-prepare-students-the-future.