The binary was always a kind of hallucination from real events. It's a toy model that uniquely (and mostly poorly) fits in our reality as simula. This article demonstrates Baudrillard was more accurate than The Matrix, ie the simula becomes seamless and transparent in our reality. It's not separate.
Software is neither engineering nor science, so the terms Software Engineering and Computer Science are mislabels at best and extinction propaganda at worst.
What I believe makes the distinction between engineer and non-engineer in the software world so difficult to pin down is that software is so powerful that most non-engineers can end up easily doing engineer-level work.
For example, a mechanical engineer is someone that designs mechanical systems. In order to do that, they will need specialized and very expensive equipment, and the end result will be produced with machines costing hundreds of thousands or even millions of dollars. Designing a system and producing a single one-off artifact are two very different things, and that's why a lone craftsman in their shed cannot do actual engineering (outside of pen and paper mockups).
With software, otoh, it takes nothing to go from default nginx for serving your static personal website to an orchestrated cluster of containers and load balancers. The problem is that, for the latter, if you haven't got an engineer-like training, you will not be able to reason about the system, because you didn't really design it.
Most of software isn't engineering, it's just building.
It's like a lot of these custom car/motorcycle builders vs actual engineers designing for a major manufacturer. You are both building a product but one places a lot more rigor on the science, data, and testing behind the decisions. That doesn’t mean the custom builders don't build good stuff, just that you won't get answers to things like how much force a particular part can take or how much energy it will absorb in a crash.
In software, you might have some people still doing real software engineering, but they are in sectors that take documentation and testing more seriously. Not that every player takes this dedicated approach, but potentially parts of auto, aviation and defense fall into this.
I always thought of myself as someone closer to a craftsman than an engineer, it's true that there's more "I think", "I believe" than verified working processes, their limits, etc.
But I also think that the software development process is maybe too flexible to be regulated, and tested like the other disciplines, a building is always a building, a material is always the same material.
But in software, who is going to test and verify the "materials" if they change constantly and evolve? It seems to me that any attempt at standardizing software development could slow down development so much that most won't find it to be worth it.
This isn't an uncommon lament, despite what the author thinks.
The problem is that running "studies" on what the author and others are asking for is effectively impossible. You can't get 25 teams of suitably-random professionals to build a non-trivial program one way, and 25 to build it another, and then do statistically-significant analysis of them, because that would be a staggeringly expensive study... and that is just for one such study, which would then be, you know, wrong, incorrectly analyzed, controversial, biased, etc. The expense of getting a representative set of such studies, independently conducted, enough to actually settle a question, beggars the imagination.
Even such studies as have been performed are almost all invalidated by virtue of being run on inexperienced students. I'm not really that interested in whether inexperienced students do or do not do well with some methodology for the most part. What happens with professionals?
In the meantime, all we've got is experiences. Contrary to popular belief, science does not mandate that we therefore curl up into a ball and cry ourselves to sleep at night. We just have to do our best. Berating other people for not pouring billions of dollars into the simplest of studies won't help much. They're still not going to, and you still have to go to work, sit down, and figure out how you're going to accomplish some task, even it you don't have double-blinded meta-analyses from decades of studies to pull from.
How many centuries did it take for civil engineering, for example, to become the codified, standardized, and respected calling it is now? While I'm sure "software development" will leapfrog that span of time, but it's only been 75 years since the discipline was invented to begin with (Lovelace's work was more applied math than anything else, but the starting point is arguably between then and, let's say, FORTRAN?).
That is to say, as a programmer, I feel like we're wading in an ocean of unknown size and depth. As we learn, by trial and error, the confines of that space will fuel the standardization and codification of the craft will only increase as a function of time until it isn't craft, but applied science.
Some programmers are engineers, but not all programmers are engineers. A lot of us are plumbers, basically. We connect together things other people have engineered. There's nothing wrong with plumbing; it's an important, honorable profession. It's just a different thing than engineering. And I'm not saying that a really good programmer transforms into an engineer by virtue of being really productive, or smart, or whatever—I'm saying engineering is a specific activity that most of us don't do every day as part of our jobs. So, to the point of this article, I'd like evidence to be gathered from engineers, specifically, and not programmers like me.
This again? In general, Software Engineering is not engineering.
It's not a technical issue, it's a 'software doesn't really kill people so government doesn't intervene in it'. In the case where the software is life and death it's generally developed in ways similar to 'real' engineering
Fundamentally folks built building/structures without engineering, just so consistently caused death and destruction that govt stepped in and started requiring licensed trained folks, approval trails etc. without this real world intervention regular physical 'engineering' the same crap shoot as software engineering.
Software engineering absolutely is engineering. Engineering is not defined by presence of regulations. Engineering is about solving practical problems within the constraints of physical reality and economics.
TFA (and your comment indirectly) seem to be about the lack of rigor in software engineering. However, any discussion of engineering that leaves out economics and costs is fundamentally incomplete.
The only reason most software development seems to have less rigor is because the economics of most software projects permit it. Other domains of software engineering where lives are on the line definitely have high levels of rigor.
Building software is usually a craftsmanship task.
Software can be engineered, but It’s rare and expensive so it’s only built that way when the cost is justified, as when building life critical systems (manned aircraft/spacecraft flight controllers) or security critical components like ssl stacks, cryptographic algorithm implementations, etc.
> More than 20 years ago, I corresponded with famous UFO researcher Stanton T. Friedman. His central claim was that “the evidence is overwhelming that some UFOs are extraterrestrial spacecraft”.
I don't believe in UFOs. But if I had to believe in UFOs, this would be my position:
We have had modern humans for 500 000 years [1]. If it takes 10 000 years to make it from stone age to space age, we have theoretically had time to make that 50 times over. Maybe there was a previous version of a human civilization [2], then wiped out by ice ages or something, but a small number of highly advanced humans have survived and keep hiding from us. I think this could be somewhat more plausible than interstellar travel.
The largest obstacle to this theory being taken seriously is the lack of evidence in long term records, such as ice cores.
Our current age will show up in future ice cores as a massive spike; we affect CO2, Methane, Sulfates, and probably a lot more. Additionally we produce and have produced various synthetic compounds that will remain detectable in the environment for hundreds of thousands of years, if not millions.
In order to circumvent this lack of evidence such a society would have had to had a very small footprint, taken very specific industrial steps, and had a focus on research that wasn't exploited. This is highly unlikely - most of our lessons have actually been learned from exploitation, and most of our research facilities require astounding amounts of labour to construct. This isn't even touching on the social improbability of maintaining such a society.
This is closely related to why Sussman and Abelson stopped teaching SICP: it is not possible to engineer software any more because systems are too complicated to completely understand and abstractions hide too many behaviors. So now we do "programming by poking" to understand what the system does instead of making it correct by construction.
The thing with software is that you need to feel the pain in order to learn something. For example, when you lose all your work due to a bad HDD, you learn the importance of backups. But we also learn from others telling you that you need backups. So you make a copy of your data, but on the same hdd. Because you really haven't learned the lesson. Same with test driven development, you can have an entire career without software regression bugs, so you have no reason to use TDD. No pain no gain!
Ask this question in the 1940s and they would tell you it’s math. We are making machines that do math to kill Nazis. Now take this vacuum tube and plug it in over there and then go get me a cigarette.
I've always wondered why UFOs are only a USA phenomenon. Why doesn't China have these extraterrestrial biological remains? What about Russia? North Korea? Japan? Because it's a form of mass-hysteria. Just like the flat Earth crowd, they will continue to shovel the narrative and ignore scientific evidence.
Software development isn’t engineering and it has never been. Software developers aren’t engineers.
I don’t know why this keeps coming up, maybe slow news day. It’s okay to be passionate about a craft or a job and for that job to be very technical and demanding. Many people feel that way about what they do, and they are perfectly okay not being engineers.
This is as much about UFOlogy as it's about SE. But there's also Science in Ufology, for example statistical analysis of reported UFO sightings or video analysis of UFO Videos. I think this applies to software engineering as well.
Here's an example I found enlightening: It's about the HTTP3& the QUIC protocol: https://www.youtube.com/watch?v=4rYPXgCKamM
So much real engineering went into that, from fossilized infrastructure that doesn't allow certain ipv6 extension headers, to assumptions about the great firewall of china and it's inner workings and more.
One big caveat to this is formal methods. If we did formal methods for all production code, it would meet the highest definition for rigor and rest safely as a true engineering discipline.
I think this eternal discussion persists because we conflate two different aspects of software engineering: the technical and the social.
Technically, we're a mature discipline. The author laments our lack of tools as advanced as architectural CAD systems, but I'm unconvinced. We have static types, tests, linters, version control, benchmarks, standard data formats and protocols, deployment orchestration, debuggers. It's pretty nice.
Socially, our discipline feels immature. As mentioned, we don't know how well TDD works, how best to write documentation, or how to pick a flavor of agile. But these are meta-problems that plague every discipline! I challenge you to find a high quality study comparing imperial vs metric units in architecture, or the ideal number of architects for a given project size.
Engineer is to scientist as builder is to engineer.
Scientists take reality observations and make theories/models/principles.
Engineers take scientific principles and make technological designs.
Builders take available technologies and make a product/object/_thing_.
In each level, understanding how your inputs work defines the minimum criteria of success, but those who take the time to understand the “why” are largely considered “the good ones”.
There are plenty of activities that are essential for engineering but not a sort of engineering themselves. Like writing documentation, or communicating requirements to your colleagues. Making instructions and operational procedures. Management. Accounting. Marketing. What makes making software an engineering discipline and making coffee not? Where is the line and why we presume we should be behind that line?
I hate the idea of having one "Software Discipline". Something is lost when people are constrained by OOP or TDD or "Clean Code". Obviously, as with the example of TDD in the article, a lot of these terms mean different things to different people. Hence whenever "Clean Code" is criticized, people who think their code is "clean" take up arms.
I tend to disagree with most of these rulesets that are meaningless to "engineering". The idea that a function should only be 40 lines long is offensive to me. Personally, I would rather have one 400 line function than ten 40 line functions. I'm a Ziguana. I care about handling edge cases and I think my programming language should be a domain specific language to produce optimal assembly.
I would not constrain other people who feel differently. I read an article where some project transitioned from Rust to Zig, even though the people on the team were all Rustaceans. Obviously their Rust people hated this and left! To me, that's not a step in the right direction just because I prefer Zig to Rust! That's a disaster because you're taking away the way your team wants to build software.
I think hardly any of the things we disagree on actually have much to do with "Engineering". We mostly aren't proving our code correct, nor defining all the bounds in which it should work. I personally tend to think in those terms and certain self-contained pieces of my software have these limits documented, but I'm not using tools that do this automatically yet. I'd love to build such tools in the coming years though. But there's always the problem that people build tools that don't notice common use-cases that are correct, and then people have to stop doing correct things that the tool can't understand.
47 comments
[ 2.9 ms ] story [ 59.2 ms ] threadSoftware is neither engineering nor science, so the terms Software Engineering and Computer Science are mislabels at best and extinction propaganda at worst.
For example, a mechanical engineer is someone that designs mechanical systems. In order to do that, they will need specialized and very expensive equipment, and the end result will be produced with machines costing hundreds of thousands or even millions of dollars. Designing a system and producing a single one-off artifact are two very different things, and that's why a lone craftsman in their shed cannot do actual engineering (outside of pen and paper mockups).
With software, otoh, it takes nothing to go from default nginx for serving your static personal website to an orchestrated cluster of containers and load balancers. The problem is that, for the latter, if you haven't got an engineer-like training, you will not be able to reason about the system, because you didn't really design it.
It's like a lot of these custom car/motorcycle builders vs actual engineers designing for a major manufacturer. You are both building a product but one places a lot more rigor on the science, data, and testing behind the decisions. That doesn’t mean the custom builders don't build good stuff, just that you won't get answers to things like how much force a particular part can take or how much energy it will absorb in a crash.
In software, you might have some people still doing real software engineering, but they are in sectors that take documentation and testing more seriously. Not that every player takes this dedicated approach, but potentially parts of auto, aviation and defense fall into this.
But I also think that the software development process is maybe too flexible to be regulated, and tested like the other disciplines, a building is always a building, a material is always the same material.
But in software, who is going to test and verify the "materials" if they change constantly and evolve? It seems to me that any attempt at standardizing software development could slow down development so much that most won't find it to be worth it.
The problem is that running "studies" on what the author and others are asking for is effectively impossible. You can't get 25 teams of suitably-random professionals to build a non-trivial program one way, and 25 to build it another, and then do statistically-significant analysis of them, because that would be a staggeringly expensive study... and that is just for one such study, which would then be, you know, wrong, incorrectly analyzed, controversial, biased, etc. The expense of getting a representative set of such studies, independently conducted, enough to actually settle a question, beggars the imagination.
Even such studies as have been performed are almost all invalidated by virtue of being run on inexperienced students. I'm not really that interested in whether inexperienced students do or do not do well with some methodology for the most part. What happens with professionals?
In the meantime, all we've got is experiences. Contrary to popular belief, science does not mandate that we therefore curl up into a ball and cry ourselves to sleep at night. We just have to do our best. Berating other people for not pouring billions of dollars into the simplest of studies won't help much. They're still not going to, and you still have to go to work, sit down, and figure out how you're going to accomplish some task, even it you don't have double-blinded meta-analyses from decades of studies to pull from.
That is to say, as a programmer, I feel like we're wading in an ocean of unknown size and depth. As we learn, by trial and error, the confines of that space will fuel the standardization and codification of the craft will only increase as a function of time until it isn't craft, but applied science.
Edit: s/applied science/engineering/
It's not a technical issue, it's a 'software doesn't really kill people so government doesn't intervene in it'. In the case where the software is life and death it's generally developed in ways similar to 'real' engineering
Fundamentally folks built building/structures without engineering, just so consistently caused death and destruction that govt stepped in and started requiring licensed trained folks, approval trails etc. without this real world intervention regular physical 'engineering' the same crap shoot as software engineering.
TFA (and your comment indirectly) seem to be about the lack of rigor in software engineering. However, any discussion of engineering that leaves out economics and costs is fundamentally incomplete.
The only reason most software development seems to have less rigor is because the economics of most software projects permit it. Other domains of software engineering where lives are on the line definitely have high levels of rigor.
I wrote a lot more in this other comment: https://news.ycombinator.com/item?id=45849304
Software can be engineered, but It’s rare and expensive so it’s only built that way when the cost is justified, as when building life critical systems (manned aircraft/spacecraft flight controllers) or security critical components like ssl stacks, cryptographic algorithm implementations, etc.
I don't believe in UFOs. But if I had to believe in UFOs, this would be my position:
We have had modern humans for 500 000 years [1]. If it takes 10 000 years to make it from stone age to space age, we have theoretically had time to make that 50 times over. Maybe there was a previous version of a human civilization [2], then wiped out by ice ages or something, but a small number of highly advanced humans have survived and keep hiding from us. I think this could be somewhat more plausible than interstellar travel.
[1] Or maybe 1 million https://news.ycombinator.com/item?id=45510582
[2] https://en.wikipedia.org/wiki/Silurian_hypothesis
Our current age will show up in future ice cores as a massive spike; we affect CO2, Methane, Sulfates, and probably a lot more. Additionally we produce and have produced various synthetic compounds that will remain detectable in the environment for hundreds of thousands of years, if not millions.
In order to circumvent this lack of evidence such a society would have had to had a very small footprint, taken very specific industrial steps, and had a focus on research that wasn't exploited. This is highly unlikely - most of our lessons have actually been learned from exploitation, and most of our research facilities require astounding amounts of labour to construct. This isn't even touching on the social improbability of maintaining such a society.
http://lambda-the-ultimate.org/node/5335
We just tinker. That's all we can do to get stuff done.
I don’t know why this keeps coming up, maybe slow news day. It’s okay to be passionate about a craft or a job and for that job to be very technical and demanding. Many people feel that way about what they do, and they are perfectly okay not being engineers.
How much of modern software practices would exist today if the senior engineer needed to sign off on a project?
Here's an example I found enlightening: It's about the HTTP3& the QUIC protocol: https://www.youtube.com/watch?v=4rYPXgCKamM So much real engineering went into that, from fossilized infrastructure that doesn't allow certain ipv6 extension headers, to assumptions about the great firewall of china and it's inner workings and more.
https://en.wikipedia.org/wiki/Formal_methods
Technically, we're a mature discipline. The author laments our lack of tools as advanced as architectural CAD systems, but I'm unconvinced. We have static types, tests, linters, version control, benchmarks, standard data formats and protocols, deployment orchestration, debuggers. It's pretty nice.
Socially, our discipline feels immature. As mentioned, we don't know how well TDD works, how best to write documentation, or how to pick a flavor of agile. But these are meta-problems that plague every discipline! I challenge you to find a high quality study comparing imperial vs metric units in architecture, or the ideal number of architects for a given project size.
Scientists take reality observations and make theories/models/principles. Engineers take scientific principles and make technological designs. Builders take available technologies and make a product/object/_thing_.
In each level, understanding how your inputs work defines the minimum criteria of success, but those who take the time to understand the “why” are largely considered “the good ones”.
And the rest is turtles all the way down.
For counter-examples see:
https://www-cs-faculty.stanford.edu/~knuth/taocp.html
and
https://www.youtube.com/watch?v=bmSAYlu0NcY
which is about the wonderful book:
https://www.goodreads.com/book/show/39996759-a-philosophy-of...
There are plenty of activities that are essential for engineering but not a sort of engineering themselves. Like writing documentation, or communicating requirements to your colleagues. Making instructions and operational procedures. Management. Accounting. Marketing. What makes making software an engineering discipline and making coffee not? Where is the line and why we presume we should be behind that line?
I tend to disagree with most of these rulesets that are meaningless to "engineering". The idea that a function should only be 40 lines long is offensive to me. Personally, I would rather have one 400 line function than ten 40 line functions. I'm a Ziguana. I care about handling edge cases and I think my programming language should be a domain specific language to produce optimal assembly.
I would not constrain other people who feel differently. I read an article where some project transitioned from Rust to Zig, even though the people on the team were all Rustaceans. Obviously their Rust people hated this and left! To me, that's not a step in the right direction just because I prefer Zig to Rust! That's a disaster because you're taking away the way your team wants to build software.
I think hardly any of the things we disagree on actually have much to do with "Engineering". We mostly aren't proving our code correct, nor defining all the bounds in which it should work. I personally tend to think in those terms and certain self-contained pieces of my software have these limits documented, but I'm not using tools that do this automatically yet. I'd love to build such tools in the coming years though. But there's always the problem that people build tools that don't notice common use-cases that are correct, and then people have to stop doing correct things that the tool can't understand.