You better unplug your keyboard and turn off your workstation. You shouldn't be designing, modeling, analyzing or coding anything because more than likely you're not an engineer. Go home, you're an imposter. That's apparently the grim news delivered by Ian Bogost of the Atlantic, who narrowly confines the definition of an engineer to the strictly traditional concept of certification and licensure. Software engineers in particular have been thrown off a bridge, it seems. It's the sort of crass judgment that might have you propelling your fist through the nearest display. But before you go off unnecessarily voiding warranties or turning to a career in Russian medieval literature, let's do what engineers do best and assess the problem systematically.
Editor's note: Once you've finished reading this piece, look to Blake's post for even more "software engineering is engineering" goodness.
The reality of software infrastructure
The central point in Bogost's inflammatory post titled "Programmers: Stop Calling Yourselves Engineers" contends that civil engineering monuments like bridges or power plants are carefully contemplated by licensed engineers sworn to defend the public good while software is anything but. Meaning that software design must be fundamentally haphazard and unreliable, thus undeserving of any reference to engineering. Referencing anecdotes about Google Docs service interruptions and bricked iPhones, he states:
"These might seem like minor matters compared to the structural integrity of your office building or the security of our nation’s nuclear-weapons arsenal. But then consider how often your late-model car fails to start inexplicably or your office elevator traps you inside its shaft. Computing has become infrastructure, but it doesn’t work like infrastructure."
Nothing could be further from the truth.
Cars are a deliciously perfect example, considering they typically carry 100 million lines of code across a particular model's numerous variants. Your late model car doesn't fail to start, despite the fact there's software in there authorizing your key fob, and making sure the brake is depressed, even before push-button start was standard equipment.
Other examples of software-driven reliable car functionality include:
- configurable electronic steering
- electronic throttle
- economical continuously variable transmissions
There's been code to manage fuel injection since the 60s. And Tesla's autopilot hasn't managed to kill anyone yet, despite some owners being complete idiots. Quite the opposite is true, some of their butts have been saved by the automatic braking system (FYI – that’s also controlled by software).
Software in cars is pretty darn good, developed in synchronicity with electrical and mechanical design in a mechatronic synthesis. This is the new reality for everything...excepting, perhaps, bridges.
Myopic at best
As for the bricked iPhones, they didn't explode last I checked. And they could be unbricked by wiping and restoring a backup. It’s important to note – if you’re the kind of person who notes things – that backups are automatically performed by default and deposited to iCloud. Huh.
Google Docs dropping out is little more than an inconvenience. Your data is still there when it comes back. Keep in mind Google Docs wasn't designed for nuclear power plants and most people don't pay a dime for it. Judging the entirety of software engineering solely from the state of certain consumer-oriented applications is myopic at best.
It's about failure modes
Most consumer applications are ephemeral in nature: what happens if Facebook crashes on your mobile phone? You look up from you phone, your greyhound stirs to life and lobbies to go outside and chase some cats, and you think that's not such a bad idea. From a failure mode standpoint, your burrito-finder and weight watcher app (sworn enemy of the burrito finder – life is complicated) don't matter at all.
Engineered software, like any other kind of engineering is designed with resiliency based on failure modes and consequences of failure. It's an essential part of understanding design requirements. That's because resiliency costs money, and here on Planet Reality engineering projects are built with finite resources. Well, at least until we engineer replicators.
Most don't wonder much about the stuff that works all the time. Like financial transactions. Or medical equipment. Or communications satellites. Or rovers on Mars and spacecraft outside the orbit of Pluto. Or how in the hell the LHC works at all (where failure modes matter). They're all running software. Engineered software, even.
To categorically exclude software from engineering is the bad kind of certifiable. In fact, it's we're-having-soup-today crazy.
The valley effect and democratization
The consternation over software engineering in specific is a direct result of software development democratization, a positive effect of advancing technology. The valley effect is a mode of thought born from this democratization makes a wildly erroneous assumption. That is, if you can use such readily available tools without poking your eye out, that alone makes you an engineer.
However, tools don't make an engineer. But principled use of a tool, as part of a larger systematic design approach certainly does.
Democratization is causing friction between those who can build things (anyone) and those who can build lasting things (engineers). And if that makes you uncomfortable, here's the bad news: this is only the beginning. As we're seeing with CAD and 3D printing right now, before too long all tools which engineering use will be democratized.
And that's not a bad thing, bro.
We lament quite a bit about engineering education and getting more students interested in STEM, access to the tools is the much needed gateway. Allowing ideas and concepts to flow from anywhere or anyone is critically important to innovation. There's a line of demarcation between an inventor and an engineer. Tool democratization allows for more inventors. An inventor, much like a scientist is about discovery, the engineer is about making it practical, safe, and resilient. You need both.
So what makes an engineer?
Is some random bro who downloads Onshape, pops out a few parts on a low-cost CNC or 3D printer and bolts everything together in his garage an engineer? No, he's just a guy who bolts things together. Similarly, if a watery tart throws some young kid Ruby on Rails to go build and launch some burrito finder, is that person an engineer? Nope. Strange people lying in ponds distributing dev kits is no basis for a system of engineering.
A larger existential question: Can actual engineers work on a burrito finder? Oh my, yes. It's not about the product per se, it's about the design process. How can you tell the difference? If you remove the creator, the original intent of how a product works, why it works, how it can fail and how it can be changed is readily apparent from artifacts: documentation, structure, and annotation. It has been built with a systematic approach, though the specific nature of those artifacts can vary in form and substance. Think of it much like the scientific method. An engineering method.
Engineering is generally recognized through study and earning a college degree. It's the single best measure we have, though a piece of paper is not a guarantee nor should it act as an exclusionary absolute. But for lawyers that's not nearly enough, they demand accountability with regard to public works. So then it is for the lawyers that there's the matter of certification and licensure. It's a matter of liability, not engineering.
Certification is not what you think it is
This is where the shoe drops for all other engineers, not just software engineers. From the Bogost article:
"Other engineering disciplines are subject to certification and licensure. If you’ve ever hired a civil, structural, or hydraulic engineer for a construction or repair project, that individual probably had to be certified as a Professional Engineer (PE). Licensing processes vary by state, but Professional Engineers generally need to hold a 4-year degree from an accredited program in their discipline, pass one or more exams, and possess 4 or more years of professional experience under the supervision of a licensed engineer."
A dismal amount of degreed engineers are actually engineers if you're using certification as a benchmark. According to the World Economic Forum, the United States produces nearly 238,000 graduates in engineering, manufacturing, and construction on an annual basis. Yet according to the NCEES, the number of individuals taking the Fundamentals of Engineering (FE) exam across all engineering disciplines from January to May of this year number only 12,835. And only 75% of those managed to pass.
You do the math (no calculus needed). It's bad enough that no one seems to be actively metering this ratio; you'd think it should be plastered all over the National Society of Professional Engineers (NSPE) website. How is this possible? Quite simply, much of what professional certification entails is heavily anachronistic and mostly irrelevant. There are a number of factors working against certification in general:
- Despite an increasingly mobile workforce, certifications are valid only in one state, and may not transfer without having to satisfy onerous requirements leveraged by each state.
- Many engineers aren't even working as engineers. Where do some of MIT's best and brightest go to? They go to work on market algorithms for banks.
- It's costly. Fees designed by state governments to fleece graduates and practicing engineers for filling out forms, obtaining certificates, and giving fingerprints. Thanks for studying so hard, now pay up.
- The process involves working under an existing PE (provided you can find one wherever you are working) for 4-5 years. Then you have to take a second exam. By the way, Millennials change jobs about every 3 years.
- Any potential salary differential for an Engineer in Training (EIT) over a regular graduate has been essentially erased by inflation over time and many companies don't see the value.
All that considered, it's a miracle anyone bothers at all. The response from insiders has been chiefly to "raise the bar" by looking at requiring graduate degrees for certification going forward. I'm sure that will just be all rainbows in the end. Interestingly, a software engineering examination was introduced in 2012, though most software engineers have no idea it exists. There still isn't an exam specifically for aerospace, students are asked to pick one of the other exams instead.
The one place where licensure retains relevancy is for civil engineers working on public buildings or running their own consultancy. The distinction? There are foundations to repair or underground storage tanks to remediate. That is why civil engineers are represented out of proportion with respect to other engineering disciplines in PE certification numbers.
But for the larger engineering community, licensing remains an anachronism, a call back to the long-eclipsed apprenticeship model, imagined during simpler times, when taking oaths and wearing jewelry might have been relatable. Where a single engineer was often a sole decision maker on a project, and some type of oversight was necessary. Most products today are considerably more complex and massively collaborative.
Take aerospace, for example, where there are no individual signoffs and everything is subject to a regulating authority i.e. the FAA. Because the design is multi-dimensional it's impossible for any single engineer to be sufficiently versed in every discipline required to certify the design. And guess what? Products of all types are becoming more and more multidimensional, one particularly active dimension of which is software. Internet of Things, anyone?
Modern methodologies, iterations, and waterfalls
The final straw in this strange journey is the unwarranted condemnation of software methodologies like Agile, designed to keep pace with ever increasing demand for rapid product development. The age of the waterfall model is over. The criticism incorrectly identifies Agile as an inherently reckless process:
"Agile software development has become predominant, focused on rapid iteration rather than long-term planning and intricate documentation."
Newsflash: all engineering is iterative. There is no requirement for engineering documentation, the artifacts of design as mentioned earlier, to be intricate. They only need be sufficient enough to efficiently communicate design intent. Methodologies like Agile aren't about dispensing with structure and documentation, but instead reducing them to their essential cores. Retaining the information that matters in as compact form as possible as the product takes shape, not as an involved setup task that delays the actual solution process. By removing unnecessary serial dependencies, and shortening the feedback loop when each new element of design is added, design matures faster without compromising its integrity. This is called efficiency.
Parting thoughts
Without a doubt, software engineering is engineering. Don't let anyone tell you otherwise. Engineering is independent of a medium, whether it's the hard physicality of metal, wood, or plastic, the data structures and algorithms of software code, or even the developing frontier of purpose-built biological machines.
Technology-driven democratization has redefined our collective capacity to manifest new ideas, but it's still the engineer's responsibility, independent of licensure of methodology, to transform those ideas into resilient designs that redefine the world. Engineers solve problems. Practical problems.
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.
