But I think it's also partly illuminating the fact that hardware engineers are true engineers, while software engineers mostly aren't.
That said, it's also on the order of a hundred years younger a discipline and our theory is not so well developed.
Yes, there are a lot of "developers". But there are also software engineers, even if our engineering craft is less-well developed by the standards of civil engineering or mechanical engineering. I understand engineering organizations (like those in Canada) who oppose the use of the term "software engineer" because there's no common code of practice or standards in the same way that those who wear the iron ring claim is incorrect.
I think that we, as a profession, need a code of ethics (and the ACM has a good one, https://ethics.acm.org/code-of-ethics/) and the application of software in certain cases should absolutely be regulated the same way that the various physical engineering practices are (healthcare, AI, finance, legal applications) so that there are consequences for the businesses and potentially the software engineers involved with those businesses when they cause harm (see sentencing guideline software in the US; see the contract that developed the Royal Mail "audit" software that could never work as advertised; see the rampant fraud that is crypto; see the abuse of generative models to software-wash copyright violations).
But the lack of regulatory bodies does not mean that there's not a practice of engineering involved, it just means that there's no regulatory body that governs said practice.
Ah yes. Meanwhile, my friend who's a mech-e at a car company starts from scratch on every single last project, never reusing components, and also machines every component from scratch because there's no such thing as McMaster or any other vendor. When he works on a project, the physical parts never ever fit together like Lego. It's not like he'd use calipers or something to do what's called measuring (twice!) so that things fit together.
There are plenty of places to demand more rigor from people writing software before considering it engineering, but reuse of parts, and having them fit together nicely is a weird one.
Yeah, no.
So an applied physicist discovers the light-emitting diode. An electrical engineer designs an LED light panel. An electrician wires light panels into a home.
Likewise, a computer scientist discovers NFA reduction, an engineer uses it to build a regular expression compiler, and a developer writes a regex to validate email addresses.
For a more principled approach, I would say (as one of these “licensed engineers who has not done as much actual engineering”) that engineering as I have seen it kind of has three really major themes:
• Prototyping/building/creation. Tinkering. I guess the reason we don't talk about this is that everybody finds it trivial? But when you talk to ChemEs and they discuss optimizing pipelines for chemical processes you do see that it can get a little abstract so it's worth pointing to as a baseline.
• An underlying scientific theory that guides the models used. Building stuff has happened since way before science but engineering is clearly a postscientific endeavor, “here’s the underlying mechanical principles of how this works.” This is probably the sketchier principle in how we talk about “is this software design really engineering,” we tend to not have a firm scientific understanding of the problem domain of building software. Some things like CAP theorem, patch theories in version control (Darcs, Pijul), distributed consensus algorithms, TCP/IP, I would say really rise to that challenge and say something hard-learned about real systems. Things like OS kernels also have so much trial and error, so much prototyping that it feels like “yes you really did do enough hypothesis-test-reëvaluate cycles that the result embodies a model of the problem domain that counts as a scientific understanding.” But a lot of our work is just gluing systems together and that seems more “electrician” than “electrical engineering.” Now, science uses math, so people think of engineering as highly mathematical, I am not sure that it has to be. Whereas I do think it has to be scientifically based.
• The last big thing that I think we don't talk about enough is risk assessment. The reason that we’re doing all of this science and math to build a bridge, is so that we can assess how strong it needs to be to just barely survive the peak loads that it will ever have, and then double that strength just in case.
I think that when we say “not all programmers are doing software engineering” a good proxy for that is looking at, first, do you have a scientific model of the sorts of approaches that you can do; and then, do you use it to assess numerically the kind of loads that your system will come under up-front and design accordingly—writes per second, queries per second—and set realistic targets and choose caching and consensus and whatever else to achieve those and measure that you have... Or do you work via crude heuristics, “we use Kubernetes so I'm sure it will scale later, we do ‘best practices’ so we don't have to think about those,” and related kludges where we can comfortably say you're just tinkering rather than being principled about it.
And then, this reveals that maybe you don't need to be doing engineering, maybe you really do just need to tinker in the problem space while you achieve better product-market fit. Maybe you are doing science rather than engineering, and that is okay. Like, the idea that you are going to launch the next space shuttle with your reliability, I am sure that makes for a very energized, focused workplace, but it's not a precondition, it's not the only way to get there.
Yes replication:
Oops we got hacked. I wonder what happens if we write insecure code again.
Oops we got hacked. I wonder what happens if we write insecure code again.
Oops we missed a deadline. I wonder what happens if we underestimate again.
Oops we missed a deadline. I wonder what happens if we underestimate again.
Engineers are good at building bridges, and artists are good at making paintings. That doesnt mean it is a good idea to have the engineers paint paintings.
Leaving aside the four splits, Civil, Mechanical, Electrical, and Electronic with the obvious corollary that few Engineers build bridges, I'm reminded of my first student Engineering project back in 1983 (ish).
Building a sheep shearing robot - hardware and software, with no pre existing libraries of control software, etc.
https://research-repository.uwa.edu.au/en/clippings/how-nece...
https://www.cambridge.org/core/journals/robotica/article/abs...
https://www.youtube.com/watch?v=6ZAh2zv7TMM
A great chunk of software was written by Peter Kovesi .. a mechanical engineer still working on computer vision projects today: https://peterkovesi.com/projects/
You sound more than a little ignorant of the breadth and depth of talent in the world and more than a little inclined to believe that people can be boxed up and ring fenced by your particular world view.
No sheep were harmed in the making of this robot. Sheep literally fell asleep when secured.
Art is for everyone. Painting is a special form of art. Math makes for beautiful art, so download LibreCAD and free your mind.
(Speaking as an ex. IT guy, ex. CNC machinist who is attending art school at the age of 40 as a form of rehab.)
If software techies/engineers wish to push back, may I suggest: Tay bridge, Tacoma Narrows, Millennium bridge and concrete cancer. Comet commercial jet airliners and the many snags that lead to fillets and rounded corners on ships int al. Do we count Titanic as "user error" or inappropriate expectations exceeded?
