What engineers have in common (part 3)

(Part 1 and part 2 of this series)

In my most recent post, I proposed the following definition (which I’ve slightly revised):

engineer: an individual who designs novel methods, devices, or systems that can be practically implemented to meet specified constraints, or analyzes existing methods, devices, or systems for their capacity to meet such constraints, while making judicious use of scientific models, mathematical analysis, and prior experience.

Engineers working in the physical realm (which I deem to be physineers) use theoretical models that capture how our universe behaves. Strong problem-solving and math skills are used to manipulate those models in a manner that leads to the creation of new physical embodiments.

I note here that working with “real world” objects, in and of itself, does not make one a physineer. A carpenter constructing wooden chairs operates in the physical realm, but we do not typically refer to such an individual as an engineer. If a chair leg were to break, a reasonable carpenter might attempt to replace the failed leg with a larger one, as simple observation of nature lends credence to the notion that bigger is often stronger. However, constructing chairs on a “trial-and-error” basis to find one that does not collapse, but does not waste material, is neither judicious, nor innovative, and is therefore not engineering. I interpret a “judicious” analysis to be a considered compromise among the various parameters influencing the work—including factors of size, weight, environment, material, maintenance, production, and cost. This often requires the development and manipulation of abstract models that permit a multitude of parameters to be evaluated. If such models have already been developed, and acquisition of a solution requires only that a predetermined sequence of computations be faithfully carried out, then the process is again not engineering, as it is not “novel.”

In contrast, a physineer might take the concept of a chair and create an abstract model that can be analyzed and manipulated. This abstraction might take the form of a free-body diagram, or a set of mathematical equations, or computer code. Important parameters could include the type of wood being used and the maximum weight that the chair is to support—as well as the equipment and methods available for fabricating a new leg. Most importantly, a physical engineer keeps in mind the eventual implementation of the modified design. There is little benefit to designing a replacement chair leg that uses an unavailable material (unobtanium), or has to be fabricated using an unreliable method, or incurs an unrealistic cost. By analyzing and modifying the model, a new design (or specific parameters to be incorporated into a design) can be established for a replacement chair leg. In this manner, physineers abstract reality, modify the abstraction, then implement the abstraction.

Key to my thinking is that engineers implement an abstraction. If there is no implementation, or at least a concern about implementation, then the effort is not engineering. However, implementations do not necessarily have to occur in the physical realm. Consider engineers who design database systems, or write system code. Instead of working in the physical realm, they may operate in an informational realm, as illustrated below. The STEM field assignments made in my previous post are still valid; however, the engineering concerns become distinctly different.

I propose that software engineers working in the informational realm be titled infoneers. To the extent they use models of informational behavior to design and implement new “methods, devices, or systems,” then they are as much engineers as physineers. They simply implement their work in a different realm, one that has its own set of entropic concerns. Rather than worrying about rust, or electrical noise, or structural fatigue, infoneers must deal with data integrity, network availability, and transactional states. So infoneers need less knowledge about physics than do physineers, but require a greater awareness of software and data theory. The function of infoneers, however, remains the same as other engineers–to implement an abstraction. If the work doesn’t lead to new code, or a new database, or a new application, then it’s not engineering.

I’ll even make the case, though it pains me to do so, that certain forms of “social engineering” can legitimately be considered engineering. If one uses models of human behavior to design a new means for altering social behavior, then that person seems to fall within my definition of an engineer. (Are marketers such individuals?) I’ll call engineers who work in the social realm to be socianeers. We can even start to match up fields of science with our new engineering descriptors. Physical scientists develop models that can be used by physineers, informational scientists create models used by infoneers, and social scientists advance models used by socianeers. However, each realm has distinct differences, and behavioral properties that are not easily mastered. Thus, crossing realms is difficult. Each has a different set of analytic tools, as well as different idioms to describe pertinent characteristics. However, though difficult, we’ll eventually see engineers starting to share approaches between realms.

Traditional engineering has already blurred the lines between physical realm sub-fields. We now have cross-discipline specialists in areas such as mechatronics, nanorobotics and bioprocessing. As technology advances, we will also begin to see cross-realm specializations. Perhaps an infostructural engineer will be concerned with how traffic and weather data is used to actively modify the structural properties of a bridge. Or a biovirtualization engineer will find ways to use time spent in a virtual environment to improve personal health. So I propose that we accept a wider definition of engineering, one that incorporates the possibility of realms beyond the traditional physical domain.

And what do all engineers have in common? They implement new things in a manner that finds an intelligent compromise between competing constraints in the realm of their expertise.

Of course, that’s just my opinion. What do you think?