I’m not a programmer!! Engineer?? - Stop Calling Yourselves Engineers.
It undermines a long tradition of designing and building infrastructure in the public interest.
In the Silicon Valley technology scene, it’s common to use the bare term “engineer” to describe technical workers. Somehow, everybody who isn’t in sales, marketing, or design became an engineer. “We’re hiring engineers,” read startup websites, which could mean anything from Javascript programmers to roboticists.
The term is probably a shortening of “software engineer,” but its use betrays a secret: “Engineer” is an aspirational title in software development. Traditional engineers are regulated, certified, and subject to apprenticeship and continuing education. Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver.
The title “engineer” is cheapened by the tech industry.
Recent years have seen prominent failures in software. Massive data breaches at Target, Home Depot, BlueCross BlueShield, Anthem, Harvard University, LastPass, and Ashley Madison only scratch the surface of the cybersecurity issues posed by today’s computer systems. The Volkswagen diesel-emissions exploit was caused by a software failing, even if it seems to have been engineered, as it were, deliberately.
But these problems are just the most urgent and most memorable. Today’s computer systems pose individual and communal dangers that we’d never accept in more concrete structures like bridges, skyscrapers, power plants, and missile-defense systems. Apple’s iOS 9 update reportedly “bricked” certain phones, making them unusable. Services like Google Docs go down for mysterious reasons, leaving those whose work depends on them in a lurch. “Your password contains invalid characters,” a popular tweet quotes from an anonymous website, before twisting the dagger, “No, your startup contains incompetent engineers.”
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.
When it comes to skyscrapers and bridges and power plants and elevators and the like, engineering has been, and will continue to be, managed partly by professional standards, and partly by regulation around the expertise and duties of engineers. But fifty years’ worth of attempts to turn software development into a legitimate engineering practice have failed.
Just as the heavy industry can greenwash to produce the appearance of environmental responsibility and the consumer industry can pinkwash to connect themselves to cause marketing, so the technology industry can “engineerwash”—leveraging the legacy of engineering in order to make their products and services appear to engender trust, competence, and service in the public interest.
NATO Science Committee sponsored two conferences dedicated to establishing an engineering approach to software creation. The 1968 conference report shows that the notion was still aspirational:
The phrase “software engineering” was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.
Commercial applications meant to service ordinary people, from inventory control to airline reservations to banking, needed to be reliable. Programming merely involved implementation.
Software-engineering trends came and went during the ensuing decades. Structured programming paradigms of the 1960s, meant to make software development more predictable and less risky, gave way to the object-oriented paradigm of the ‘80s and ‘90s, meant to make programming better mirror the business processes it facilitates.
A decade after his 1975 intervention The Mythical Man-Month: Essays on Software Engineering, Fred Brooks lamented that little had changed. In response, he proposed incremental development, or prototyping.
As a result, software development has become institutionally hermetic. And that’s the opposite of what “engineering” ought to mean: a collaboration with the world, rather than a separate domain bent on overtaking it.
TAKE AN ACTION! THE FIRST STEP IS CONNECTING. info@devspark.lt