wgroeneveld
/
brainbaking
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

software engineering is (not) engineering

This commit is contained in:
Wouter Groeneveld 2022-10-10 10:24:14 +02:00
parent c8b737215f
commit 675dcef73e
2 changed files with 54 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/post/2022/09/the-creative-programmer-early-access-release.md
View File

@ -23,7 +23,7 @@ Well, _groundbreaking_ is probably quite exaggerated, but still. It's a technolo
> Inside The Creative Programmer you’ll learn insights into creativity like: The seven dimensions of creativity in software engineering, The scientific understanding of creativity and how it translates to programming, Actionable advice and thinking exercises that will make you a better programmer, Innovative communication skills for working more efficiently on a team, Creative problem solving techniques for tackling complex challenges.
Check out the book at [https://www.manning.com/books/the-creative-programmer](https://www.manning.com/books/the-creative-programmer). If you apply code `mlgroeneveld`, you get 40% off (until 7th of Oct)!
Check out the book at [https://www.manning.com/books/the-creative-programmer](https://www.manning.com/books/the-creative-programmer). If you apply code `au35gro`, you get 35% off! That discount code is valid indefinitely. Be sure to also check out [Manning's new releases deals](https://deals.manning.com/new-releases-on-sale/).
You get chapter 1--4, and 5--9 have been written but are currently in peer review. Expect more to be added gradually very soon, which of course are added for free if you buy it now. The contents is based on our [exploration of creativity in software engineering](/post/2021/01/what-is-creativity-in-software-engineering/), and focuses on those seven main themes: technical knowledge, communication, constraints, critical thinking, curiosity, creative state of mind, and creative techniques.

53
content/post/2022/10/why-are-software-engineers-engineers.md Normal file
View File

@ -0,0 +1,53 @@
---
title: Why Are Software Engineers (Not) Engineers?
date: 2022-10-10T08:53:00+02:00
categories:
- programming
---
Ever since a professor of a neighboring university remarked "I'm most proud of my graduates when they just call themselves _programmers_"---while he clearly loves his status as Prof. Dr.---I've been wondering: is there a thematic or conceptual difference between a programmer, a developer, and a software engineer?
Clearly, the job title indicates some form of status, although I have non idea why, to be honest. At my first job, HR managers used competence matrices to scale their pawns---erhm, employees---across different tracks, which determined the thing we all care about: salary. Each box you were shoved in came with a label, meaning it becomes easy for your peers to guess which box you're in, making way for the inevitable comparison and unhappiness. Labels like these, from worth less to more, optionally prepended with "junior", "senior", "solutions", "enterprise", etc[^man]:
[^man]: Let's not get started on the ridiculous "engineering manager" thing.
1. Programmer
2. Developer
3. Engineer
4. Architect
In meeting rooms, when the engineer or architect has something to say, you better listen as a mere developer! Of course that doesn't sound right, but in practice, that's what's going own under the hood. The question is: why are we so attached to those words, and especially the term **engineer**?
For one, because the HR matrices tell us that engineers make more money than programmers. But why, what's the difference in their day to day job contents?
Many folks interpret the term "programmer" as a _bricolage_ person who just happens to put stuff together, press compile, and voila, it works! Programmers are viewed chaotic, have no moral compass and supposedly don't care about ethics or quality. They probably also don't know how to code and thrive in a team. Then you have your "developer", a sometimes seen as evolved version of the programmer who is able to read an API documentation and can perhaps "develop" their own.
But what bigger companies _really_ want to hear (and see), is the **systematic appliance** of best practices, from design board to tests to deployment and long-term support. Both IEEE and ACM, two hugely influential computing learning societies, define software engineering as a systematic engineering approach to software development. Engineers---the real ones---are process experts. They design, divide into subsystems, make prototypes, evaluate outcomes, specify tests, and provide maintenance.
While that all sounds very appealing, it also reeks of a pre-set waterfall process that is almost impossible to change. Then came along agile software development, and suddenly, calling yourself "agile" was more popular than calling yourself "engineer". We aren't afraid of change! Got a deprecated API? No problem! Your test suite is falling apart? We're here to fix that! Prepending _agile_ to the job title _software engineer_ is making fun of the term _engineer_.
Creating software---to avoid having to use "develop" or "program"---is about exactly that: coping with rapid change. Civil engineers don't have that problem when constructing a bridge, although of course innovation is also present in that field. Although I sincerely hope they don't feel as much pressure as JavaScript developers---I'm sorry, engineers---do, when looking at [The State Of JS](https://stateofjs.com/en-us/). Rapid change and the virtual process of creation speaks against the engineering part of the software engineer.
So what else? Perhaps an important aspect that plays a role: jealousy. "True" engineers (this is getting complicated) are allowed to call themselves that: "Hi, I'm an engineer." could be answered by "Oh really, can you show me any proof", to which the engineer says "Sure, here's my _engineering_ degree". In Belgium and The Netherlands, the engineering title `ir.` and `ing.` are legally protected. The Dutch word "ingenieur" thus can't be simply translated to "engineering" because in spoken language you can "engineer" (design/create) a new pancake in your kitchen: it's frequently used as a synonym for expert or designer.
Certification in terms of a university degree is what truly allows for the title of engineer. But universities have been cheating as well when it comes to luring students in with exactly that. I studied _informatics_ (literally translated), which is called computer science (CS) at other universities. I can't legally call myself an engineer. But nearby universities started integrating an engineering degree in the CS programme: if you study CS there, you also get a civil engineering degree. They successfully managed to convince hundreds of students to opt in, thereby stealing funds from less pretentious universities. STEM education, another recent and very hip phenomena, plays out its `E` letter very well.
That means both universities and companies play a part in the pretentiousness of the title "engineer".
There have been plenty of efforts to formalize the software engineering field, for instance by the rigid enumeration of requirements. We all know that simply doesn't work in this virtual ever-changing tech industry. Even IEEE/ACM and ABET university accreditation program attempts are futile: the design, publication, and approval process takes so long that by the time it gets green light, there's need for a revision. If you read those papers (don't, but I have to), this is effectively what is happening since 2004. To make matters more confusing, software engineers can be members of IEEE, the Institute of Electrical and Electronics Engineers (you know, the real ones).
Confusing job titles aside, we all agree that programming involves much more than typing code on a keyboard: it requires thinking ahead, dividing tasks into sub-tasks, rigid (and hopefully automated) testing, re-writing and re-designing, optimizing, packaging, deploying, ... Some say that this is the difference between a programmer and an engineer, but I beg to differ: a programmer is of little use if all they can do is code. While most physicists and mathematicians also "program" (who doesn't?), they care less about code quality and long-term support of that code. There's a big difference between programming throwaway code to execute experiments and a huge software application that gets rolled out to thousands of customers.
It all started to go wrong in the sixties when the term software engineering was introduced by the NATO Science Committee that initiated engineering conferences dedicated to software creation. The conference report stated:
> 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.
Provocation, really? By replacing "development" with "engineering", the whole endeavor suddenly was elevated to a true discipline (cough).
In Silicon Valley, everybody's born an engineer. Heavyweight champions like JBoss and Glassfish together with the banking industry have turned software engineering into _enterprise_ software engineering. Academic researchers that wanted to distinguish themselves from other computing researchers turned it into _empirical_ software engineering. And then HR managers invented yet another step on the career ladder with engineering _architect_.
When I call myself software engineer, I suddenly get more respect from big companies. I can only conclude that the title software engineer is a piece of recent cultural heritage that originates from jealousy and pretentiousness, only made worse by the tech industry and its hiring process. If engineering is the application of scientific and practical knowledge to invent, design, build, maintain, and research, then of course software engineering is engineering.
Except that it isn't.