Engineer, Get Over Yourself

Tacoma Narrows Bridge Collapse

Ian Bogost’s “Programmers: Stop Calling Yourselves Engineers” in the Atlantic, claims “The title “engineer” is cheapened by the tech industry.” He goes on to state:

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.

Those engineering disciplines are subject to both professional and legal regulations, it’s true. That being said, bridges, buildings, and power plants (as well as power grids are not immune to failures. Spectacular failures in regulated disciplines, even when they spur changes, can still recur.

Fifty years might seem like a long time, but compared to structural engineering it’s nothing. Young disciplines have a history of behavior that, in retrospect, seems insanely reckless (granted, he wasn’t a nuclear engineer, but at the time there weren’t any). Other disciplines, now respectable, have been in the same state previously.

Bogost complains about the lack of respect for certifications and degrees, but fails to make a case for their relevance. He even notes that the Accreditation Board for Engineering and Technology’s “accreditation requirements for computer science are vague”. Perhaps software development is too diverse (not to mention too much in flux) for a one-size-fits-all regulatory regime. Encouraging the move toward rigor, even if the pieces aren’t in place for the same style of regulation as older engineering disciplines, seems a better strategy than sneering about who should be allowed to use a title.

I’m all for increasing the quality of software development, especially for those areas (e.g. autonomous cars) that have life safety implications. When I’m in the cross walk, I’d prefer that the developer(s) of the navigation system considered and conducted themselves software engineers rather than craftsmen. By the same token, I’d prefer that the consideration be a function of real rigor and professional attitude rather than ticking boxes.

[h/t to Grady Booch for the link]

2 thoughts on “Engineer, Get Over Yourself

  1. Software engineering has a horrible track record of mediocracy and even poor ethics.
    Moreover, a considerable proportion of “engineers” are familiar with the term eXtreme Programming, and still don’t practice any Test Driven Development, Refactoring nor Pair Programming.
    To make things worse, a programmer doing testing work is often considered “not our job”, or “we/they get paid too much to bother our/themselves with testing”
    Software programming, in most cases, is not scientific. But using simple methods, such as XP, does add scientific principles to programming.
    So it doesn’t matter if you call it engineering or craftsmanship – either case, we suck, big time.

    Like

    • “Software engineering has a horrible track record of mediocracy and even poor ethics.”

      Absolutely. No argument at all. But, go back less than a 150 years ago and substitute “medicine” for “software engineering” and you the statement remains true.

      We need to suck less and promoting professionalism is a much better way to do that than just snarking about titles (which is essentially what Bogost’s article was). This quote, for example: “…but its use betrays a secret: “Engineer” is an aspirational title in software development.”. Yes, yes it is. As an industry, we’re not there yet. However, I see “aspirational” as a positive where he, obviously, does not.

      Getting there is going to involve a lot of systemic change. We can regulate programmers and programming all day long and it won’t make any difference whatsoever if we don’t change the whole environment in which it takes place. Coding is only one part, not the whole. Changing that environment starts with understanding that it’s a lot of very different environments – we can’t mandate one set of practices, etc. that will work across the board (well, we obviously can do that, but we shouldn’t if we expect things to improve).

      Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.