Recently, a publication I respect published a poorly contrived article that makes its author seem hopelessly out of touch (but has probably been a windfall for their ad department). The author of “Programmers: Stop Calling Yourselves Engineers” asserts that programmers aren’t doing the same caliber engineering as engineers who make physical things and are therefore unworthy of the label “engineer.” Now, the internet is aflutter with people agreeing that someone on the internet is wrong.
Editor's note: Once you've finished reading this piece, look to Ed's post for even more "software engineering is engineering" goodness.
As a mechanical engineer who has spent his career making software for other engineers, I’ve spent a lot of time thinking about what engineering means versus science and other kinds of technical work. Over the years, I’ve heard diverse theories about kinds of activities that people with different titles may or may not be capable of. Usually, these theories expose some sort of agenda. Have you notice how some CAD vendors use the term “engineer” to describe their users, whereas other CAD vendors are careful to avoid the term, preferring terms like “operator” or “designer”?
Activities versus professions
Instead of labeling people based on some role or skill set, it’s more helpful to describe activities with those labels. Different kinds of tasks require different kinds of thinking, each of which require different skills and approaches. On a daily basis, I find myself jumping between about five different mindsets. Here’s how it breaks down:
- Engineering: delivering specified results within a tolerance
- Science: discovering empirical truth by using experiments to justify theory
- Technical work: using technology for its intended purpose without attempting to innovate
- Art: producing results that feel correct emotionally
- Management: trying to get other people to do any of the above work
Engineering
The art of engineering is knowing what your tolerances are, and what trade-offs you can balance to achieve the needed results. To engineer anything, you must be granted a set of requirements, where each requirement is either an acceptable range of measurable values or preference to minimize or maximize such values. For our purposes (and, indeed, anyone’s nominal purpose), this is what I mean by “tolerance.”
If I ask you to make a 1” cube, you can’t really start engineering until you know what dimensional and geometric tolerances I require, not to mention all of the other information required to choose a material and manufacturing process.
When engineering a one-off, high budget project like a bridge, significant rigor is required at all levels of engineering. Therefore, there is significant up-front planning and engineers must hold professional certifications to ensure a bare minimum aptitude. When making software that needs to be easy to learn, too much up-front planning without feedback is often a waste of time, as design teams become comfortable with their work instead of learning how it’s perceived.
In all cases, there is a tradeoff of cost, time-to-market, and efficacy that are inevitably intertwined. There is also a fundamental question of whether a certain design is good enough to ship, where “good enough” typically means that it will meet customer or market expectations.
Science
Science, on the other hand, cares little for tolerance. If someone discovers that there is a truer way of describing something, that scientific achievement that usually finds its way into the literature.
Engineering and science are intertwined. When designing scientific experiments, there is often a lot of engineering to design the experiment and the equipment needed to perform it, but the pursuit is pure science. One could also argue that the process of building consensus around scientific results resembles engineering in the sense that not all science is known, and therefore consensus can only exist to within a tolerance.
Most software companies might not appear to do a lot of science (the R versus the D in R&D), but a scientific mindset often balances requirements-oriented engineering. Much of quality assurance is using scientific tools to evaluate product fitness. Lean product development and six sigma organizations foster a culture of using scientific methods to measure results and empower individuals to act on relevant empirical data. Product teams often design experiments, such as observing users and A/B testing, as a means to engineering the best result. All three examples represent a shift in thinking style from engineering to science.
Following and defying the rules
If you use a tool like a CAD package to document something you already know, maybe while adding in some details that are obvious along the way, then you are just doing technical work. The same can be said of writing a static HTML page or painting a fence.
Usually there isn’t a clear line between engineering and technical work. For example, a part that is a simple technical activity to create on a 3D printer could be an engineering challenge on a CNC machine or vice-versa, depending on the geometry. Or, if you’re digging a ditch, there might be a little planning involved, but eventually it will come down to being good with a shovel and using it for a long period of time.
On the other hand, sometimes you choose to not follow the rules, instead going with whatever feels right. Subjective human behaviors have enormous market power, and some product designers amazingly intuit and manifest novel ideas out of thin air appeal to other people’s emotions. In consumer products, the arbitrary output of these artist-prophets effectively becomes a constraint to engineering. In other industries, sometimes there are no designers to provide such styling to engineering – leaving individual engineers to seek objective functions for their ideas. The next thing you know someone has colored the "Ok" and "Cancel" buttons green and red with the justification that your customers are also engineers and therefore will “get it.”
What both the rote and creative activities have in common is that they lend themselves to long, continuous activity. It’s just as possible to sit in front of a CAD seat for all waking hours, days in a row, as it is to sculpt or paint. Some might use the term “flow” to describe this kind of thinking. Engineering and scientific thinking, on the other hand, are necessarily punctuated by results becoming assumptions and iterating. Some workflows require a combination of skills in close proximity, but are performed serially. For example, feature-based CAD systems, when used correctly, require serious engineering of the feature hierarchy while flowing through either mostly or aesthetic design activity.
Specialization
Why be put in a box? Regardless of your role and title, inevitably your job will require these different kinds of thinking. Don’t worry about what’s on your business card. Instead, when confronted with a problem, try to be conscientious about the role you are playing. Sometimes it help tease out the problem. For example, when agreeing to do any kind of work, think like an engineer and make sure you have defined what tolerances you need to hit to call a project “done.” Or, when performing an activity like testing, you might “time box” until the appropriate amount of rote work is done, so you can perform science on the data, later to ascertain whether your quality is engineered to within your customer's’ tolerance.
Of course, if you are confronted with a problem and your instinct is to get someone to help you solve it, you might want to consider a future in management.
Modernize Your Engineering Curriculum
This eBook is aimed at the engineering professor, new or experienced, that is interested in how their peers are thinking about the challenges associated with modernizing their curriculum.
