alt Hacker News"Software Engineering" Is Not Engineering (2005)
Comments
From knowing many different types of engineers, not only does software engineering fall pretty neatly within that group of jobs but also software is an integral part of their engineering practices. I know some people who are designing planes and if software isn't an engineering discipline I guess I need to tell them they recently became not engineers (though maybe because they occasionally use physics equations the author would say they still are. It's a silly distinction). The argument seems mostly based on their personal definition of engineering, which doesn't seem useful to me (a quick reading of a dictionary would make it seem that software engineering false very neatly within definition 2b https://www.merriam-webster.com/dictionary/engineering)
Overall though I found this post incredibly hard to read. It's incredibly long and wordy though that's par for the course for these petty semantic arguments.
Skimmed through, and it sort of confirms my own experience: when a problem isn't approached with an engineering mindset, the resulting work also doesn't qualify as engineering.
The article seems to make some fairly confusing statements. Why is the bar higher for software engineering, than that of civil engineering otherwise? Statements such as:
> "there is no objective reality inside software"
> "if there are many solutions to the same problem, which one is "better"?"
Is the exact same subjective goal that a objective engineering constraint has in any other engineering field. There are many ways to design and build a bridge, but the engineering aspect of it needs to model reality and account for it in such a way that the bridge to build conforms to said requirements, in a provable way. That's why engineers can be held responsible when mistakes are made.
Software Engineering can be done in the same way. This, however, depends entirely on the culture. My first decade in the field, I was fortunate to only be exposed to en environment and culture that developed software in a provably correct way, or at the very least, aspired to. The latter decade, not so fortunate. With the advent of generative AI, it's become far worse. The challenge is to carve out enough space outside the purview of "management" that wants problems solved with particular tools, regardless of applicability to said problems, and it's becoming insurmountable. Signal to noise disappearing. The idea of buying land and tending to a farm, evermore appealing.
I wonder if the author perhaps has not worked on software that comes with actual engineering constraints. There are plenty of software systems where <if it doesn't work as it should>, people die.
Why don’t we just call ourselves programmers and save this semi-regular debate!
Crypto is not the OG cryptography! GenAI is not the OG AI!
Language is for us, not the other way around. It's common usage changes.
Except for when it is, the constraints of software engineers has always been bound to the constraints of Classic Computing, but over the years we've abstracted that away to the point of where many in the field may not even realize it.
Fine, but then what am I? I'm certainly not a scientist. And calling me a "programmer" is like calling an accountant a "calculator".
I design solutions to computational problems. I also happen to implement them a lot of the time, because code was trivial to implement even before LLMs. What does that make me if not an engineer? I'm open to suggestions.
If only there were "real" engineers who could answer this question... https://www.hillelwayne.com/tags/crossover-project/
Thankfully; else we'd have big heavy things with real claws and kinetic force grabbing at us endlessly, snatching our wallets with too much precision. We'd need Arnold not AdBlock, just to leave the house.
I'd say software engineering better fits economics these days. Maybe with a Psych major to maximize the dark patterns.
Dave Farley has done some writing on what makes "Software Engineering" "Engineering"
e.g. his 2021 book " Modern Software Engineering"
> Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.
https://www.davefarley.net/?p=352
https://www.goodreads.com/en/book/show/57345270-modern-softw...
>An engineer's model must be tightly bound to the laws of physics and chemistry.
Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too.
>Software is a lot like math,
Probably referring to computer science. Computer science is neither about computers nor is it a science. It is a math. Software is like math but applied.
>The only limitation is the imagination of the creator of the virtual world (and perhaps the pesky limitations of computer resources)
computer resources: AKA physical laws. And these "laws" highly limit us in what we can do. We are definetely not operating in some kind of playground where we can be virtual gods, not even close, that's why entire swe teams are involved and paid a lot in software.
Honestly the main difference between "Software Engineering" and "Engineering" is that software is more an "art". We make up a bunch of technical nomenclature for it (like design patterns which sounds technical but is mostly made up and more artsy then say statistical mechanics) but it's mostly similar to sculpture or some artistic creation as we sort of piece everything together by instinct.
The difference between this and engineering is usually engineering involves mathematical modeling and testing heavily in development, while software engineering (usually) does not involve mathematical modeling and software testing is more of a catch-all to find bugs.
Type checking is mathematical modeling, but I wouldn't call it the core of software engineering. I guess this is where the categories get blurry.
> 429 Too Many Requests
This is definably not engineering.
Not even “engineering” is engineering. It’s equal parts art, craft, and science. And I say that as a classically trained engineer turned software engineer. Every engineering design is a compromise - it can be light, or easy to make, or robust, or cheap, or anything else driven by requirements. There is no such thing as an optimal design unless you pin the requirements down really tight - and this is where the art part comes from.
With “classic” engineering at least you have the immutable laws of physics to judge your work, but with software we have no such luck - software is infinitely pliable in ways equivalent to bending the laws of physics in classical engineering. Your bridge may not be sound at one Earth gravity, or your software might not work reliably with a gigabyte of memory, but it’s like we can place your bridge under half G by giving the software twice as much memory. And we can do all that after building our “bridges”.
I would even suggest software engineering can also be described as “applied poetry”, where we write precise prose designed to elicit specific responses from machines, but I guess that analogy was taken by “prompt engineering”, which feels like “applied sorcery”.