4 ms·

"Software Engineering" Is Not Engineering (2005)

50 points by abrbhat 3mo ago

SideburnsOfDoom 3mo ago
> 429 Too Many Requests This is definably not engineering.
- abrbhat 3mo ago
  The link is from Internet Archive. The original post was on geocities which has long been dead.
threethirtytwo 3mo ago
>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.
- whateverboat 3mo ago
  Also person month is a very solid limitation.
- baq 3mo ago
  > software engineering does not involve mathematical modeling it absolutely can, approximately nobody was doing that because it was insanely expensive. if we narrow down the definitions, modern static typing (where modern means universally accepted nowadays) is a form of mathematical modeling and proof construction that software does what it says it does. the economic calculation is changing extremely rapidly now with LLMs though. some of my software is now proved to be correct at some levels, e.g. I heavily (that is, LLMs I pilot) use TLA+ for tricky but nowhere near foundational distributed systems work (as in, I don't work on core S3, but do distributed transaction stuff).
  - threethirtytwo 3mo ago
    Yeah if you read further I mention the exceptions. Generally speaking though we don't do mathematical modeling. Basic Type checking is as far as we typically go.
- abrbhat 3mo ago
  > Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too. Agreed. If I have to guess, the relevant fields in physics for software engineering would be quantum mechanics and thermodynamics. Of course, we don't see any direct relation as of now but it feel it should be important to determine the physical basis of software. The basis of software cannot be just math. It has to be physics.
- bob1029 3mo ago
  > Computer science is neither about computers nor is it a science. https://youtu.be/-J_xL4IGhJA https://youtu.be/-J_xL4IGhJA
- AnimalMuppet 3mo ago
  > > 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. No. Software is only loosely bound by physics and chemistry. Sure, the bounds exist - they're real - but most software, most of the time, does not bump into them much at all. But > > An engineer's model must be tightly bound to the laws of physics and chemistry. is also wrong. This is using a pre-software definition of engineering to try to define software engineering. It would be like trying to use a pre-Faraday definition of physics to define microwave engineering.
SideburnsOfDoom 3mo ago
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.davefarley.net/?p=352 https://www.goodreads.com/en/book/show/57345270-modern-software-engineering https://www.goodreads.com/en/book/show/57345270-modern-softw... https://productdeveloper.net/modern-software-engineering/ https://productdeveloper.net/modern-software-engineering/
- TomOwens 3mo ago
  Dave Farley's book is really good, and I'd highly recommend it. However, I do have an issue with his focus on applying science in the definition, even though it doesn't come across in his final conclusions. In the history of engineering, that's a relatively new development. It started, to some extent, in Europe in the 1700s, but it really took off in the 1920s and exploded in the United States after World War II (1940s-1950s). It culminated with the Report of the Committee on Evaluation of Engineering Education (the Grinter Report) in the mid-1950s. This isn't to say that science isn't important to engineering, since it absolutely is. Science provides knowledge used to better understand the world being changed by engineering. But there are also plenty of examples of engineering going ahead of science - the steam engine, the airplane, generative AI. We didn't fully understand the governing rules before the technology existed. Any definition of engineering needs to be broader. Ferguson (Engineering and the Mind's Eye), Florman (several works, but primarily The Existential Pleasures of Engineering), and Vincenti (What Engineers Know and How They Know It) all explore ways in which engineering can't rely on science alone. I think Koen (Discussion of the Method) puts it best, where the application of science is one heuristic that engineers may choose to draw upon.
  - skydhash 3mo ago
    > However, I do have an issue with his focus on applying science in the definition, even though it doesn't come across in his final conclusions I don’t think it’s about science. It’s about the scientific method. From wikipedia The scientific method is an empirical method for acquiring knowledge through careful observation, rigorous skepticism, hypothesis testing, and experimental validation You don’t have to have a full theory or model to follow. You also can follow your intuition and use your creativity. You just have to carefully compare your results to your goal.
eth0up 3mo ago
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.
magarnicle 3mo ago
If only there were "real" engineers who could answer this question... https://www.hillelwayne.com/tags/crossover-project/ https://www.hillelwayne.com/tags/crossover-project/
cognitiveinline 3mo ago
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.
- andy99 3mo ago
  Engineering is a regulated term, afaik that’s what underlies the debate, it’s not about whether English has changed.
  - mfer 3mo ago
    Engineering is not a regulated term everywhere.
    - GroksBarnacles 3mo ago
      It many countries it actually is, if you call yourself an engineer professionally without a license you can be heavily fined. Canada, Germany, France..
      - stymaar 3mo ago
        I don't think you can be fined in France for that. Though I think you'll be fired without compensation or unemployment benefits.
    - analog31 3mo ago
      In the US, professional licensure is left to the states, and most states have some form of licensing for engineers along with reciprocity for transferring a license from one state to another. Commonly, engineers have an "industrial exemption" if they work for a company that makes a product rather than offering engineering services directly to the public (such as a civil or structural engineer might do). I've held an "engineer" title at my day job from time to time, though I'm not an engineer and have no engineering degree. Only a couple of engineers at my work site have licenses. On the other hand, my brother in law was a nuclear engineer, and all of the engineers at the power plant were licensed. One thing you'll notice is that small companies that do contract or consulting work will call themselves "research" or "technology" rather than using the E word on their web page.
ed_elliott_asc 3mo ago
Why don’t we just call ourselves programmers and save this semi-regular debate!
- CuriouslyC 3mo ago
  Because that diminishes the work people do. A programmer takes logic and encodes it for a machine to execute. Being an engineer suggests solving problems and defining logic. The engineer title is apt in my opinion, because if you look at construction as a parallel, the architect designs the shape of the building, engineers determine how to build it so it doesn't collapse, and builders actually make it real. Programming is like digital building, the architecture and implementation details are both separate.
- IAmBroom 3mo ago
  Centuries of accumulated respect for the word "engineer", implying a specialization that can't be simply replaced with other skill sets. That is: prestige and therefore economic incentives.
- ryandvm 3mo ago
  Because I haven't been allowed to program for 6 months. Now I'm just an AI manager.
- apple4ever 3mo ago
  Because we believe engineering fits more closely.
rkozik1989 3mo ago
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.
CivBase 3mo ago
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.
- bitexploder 3mo ago
  I just work here. The label is for everyone else :)
- jeddy3 3mo ago
  Software developer?
  - CuriouslyC 3mo ago
    If someone told me I couldn't call myself an engineer and instead I had to call myself a software developer, I'd turn around and tell them I just forgot all my theoretical computer science, and of course we can do a bubble sort on the multi-terabyte database, LOL.
- skydhash 3mo ago
  I think engineering is about norms and regulations. Creating solutions for problems can be done in a very wide spectrum, but the restricted window where you try to respect books of rules is what people call engineering.
okamiueru 3mo ago
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.
rbanffy 3mo ago
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”.
- Fire-Dragon-DoL 3mo ago
  Did you just call me poet sorcerer? Lol Cool analogies
  - rbanffy 3mo ago
    My wife says I’m a computer charmer. I prefer to say I write executable poetry that moves the hearts of machines.
    - Fire-Dragon-DoL 3mo ago
      Ah! Unfortunately machine aren't prone to cuddles,lol
- summa_tech 3mo ago
  Right! I think a lot of people, who have not done a lot of "things you can kick" engineering, have a very romantic view of it. Especially the relationship with whoever is nominally setting the goals of the project. The physics works perfectly, of course. But physics is only a third of the constraint in engineering. The other two thirds are project goals and convention. Project goals are horribly underspecified, every time. It's incredibly rare to be given a project that is completely constrained on that side, and if you do get one, most of the time it's physically impossible to achieve. This is because the people who write those specifications not doing engineering, they're doing marketing or sales or just had a cool idea. Sometimes that can even be the engineer themselves :-) So it's up to the engineer to fill in the gap, and they do it with experience and a sense of aesthetics, of sorts. Convention is what constrains the physical possibilities of engineering to the practical. Yes, you can build anything and make it work, possibly even better than what everyone else builds. But you will have to invent and construct a lot of new technologies before you can build your perfect mousetrap. So, you settle on standard components and build a decent one instead. But this introduces a gap between physics and engineering, too. A bit of no-man's land that you can reach into to produce truly great results. But it's up to the engineer to know when it's worth it.
deleted 3mo ago
[deleted]
tdb7893 3mo ago
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 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.
- bee_rider 3mo ago
  Engineers use software and inevitably some will improve the software as they use it. I’d draw a distinction between engineering using software, and engineering the software itself, though. It becomes a bit blurry—I’d say using the Matlab command line is not necessarily software engineering, it’s using a tool for engineering that happens to be made of software. But you can also write your own Matlab code, so if we want to say there’s software engineering I guess there’s no reason it couldn’t be done in that environment. IMO, I’ve never been all that concerned as to whether the “engineer” label should apply to me (coming from an engineering education but mostly looking at software). It’s more about having a professional obligation than any great feats of skill anyway, and since an obligation is mostly just felt in your head, you can give it to yourself.
defmacr0 3mo ago
The article is "not even wrong". Most of the argument just circles around an inconsistent definition of what "real world" means. > Remember "imaginary numbers" from algebra? You could do funky stuff with them like take the square root of negative nine. Imaginary numbers are generally useless for the physical world that we experience. However, they turned out to be very useful in the field of electronics. More specifically, they had predictive power in the field of electronics. Using imaginary number math, one can predict behavior of electrons and the accuracy of such predictions in models can be measured. Like here, I struggle to understand what the point is. Is predicting the behavior of electronics "useless for the physical world we experience"? And that's ignoring the author's apparent ignorance of all the other ways in which complex numbers are useful in the physical world besides taking negative numbers' square roots.
aregue 3mo ago
I had a professor that used to say that engineering is modelling problems with a set of differential equations and finding a numerical approximation to the solution. No differential equation ==> Not engineering.
FatherOfCurses 3mo ago
Engineering is a profession where individuals are certified by a governing body and required to maintain that certification through continuing education. The reason for that certification is because failure to follow the principles of the governing body can lead to injury or death, or to a lesser degree significant costs. Given all the ways that software can have those same significant impacts, I believe that there should be some sort of level at which software developers are called engineers. However, I believe that designation should come with all the professional oversight that other engineering disciplines have.
- sys_64738 3mo ago
  Real engineers have to sign off their professional reputation against what they do. Software licences say that the software is provided as-is with zero liability. Calling software developers as "engineers" is just not the same thing.
jerf 3mo ago
Yes, it is: https://jerf.org/iri/post/2026/programming_is_engineering/ https://jerf.org/iri/post/2026/programming_is_engineering/ That said, there's been a lot of changes since this was written that was relevant to the point being made, so I'm not sure I necessarily disagree with the article as written at the time. If we take the metric I used in that blog post and asked "what if we were handed current-gen AI in 2006, how well would it do?", my answer is that it would do noticeably less well. This is even more true if we instead go back to 2006 and use current hardware tech but have to train on what was available at the time. Source control was fairly popular at that point, although it hadn't penetrated everywhere yet. I don't recall a lot of curmudgeons complaining that Real Programmers Don't Need Source Control at the time, it was pretty obvious that a record of what was happening in the source code base was useful. However, IIRC, in the open source world we'd mostly have been on cvs. svn was well into the process of eating it but still had a ways to go yet. "git" had just barely been born and it would be years before it was a serious force. Beyond that, a lot of stuff I take for granted in the engineering domain was either immature or non-existent. I was on the cutting edge bothering everyone about the importance of unit testing. There were communities like Perl that had a strong culture of it and a lot of support, but still a lot of people who would use it without that and a lot of language communities without the culture. A lot of projects banged together their own haphazard solutions, but a lot of projects just went without. No devops. Metrics was something I'd never really heard of. Logs probably went to your disk and the idea of unifying them was just at the beginning. QA was much less established. QA was generally not a team that would be using much automation, it would be all hand testing. CI/CD wasn't a term yet because hardly anyone had anything even resembling it. Bug trackers were still pretty bad and not everyone used them. I'm sure a lot of people will go "yeah, but I was programming in 2006 and I had all those things", because there were certainly teams that did. Go look at Microsoft Window's dev team, for instance, and they'd have most of what we'd consider a modern development stack, albeit with some quirks we'd find odd. It's not that none of this existed, it's that it wasn't considered just the baseline for a project to be minimally competent the way it is now. And rather than the programmers having an abundance of free options and an even larger abundance of paid and hosted options, to the point it's hard to poke through them all, they're using one of a few very expensive vendors or they put it together themselves. Introducing an AI into a code base of tens or hundreds of thousands of lines, with minimal testing, trained on the code practices of that era... a modern programmer could probably still work with it. You could tell it about unit testing and it would know what you meant, it would probably just need to be prompted to do it. You could put together unified logging with some work. You could solve the problems... but your solutions would basically be putting in those 2026 guard rails. You'd have the same uphill battle convincing people of the time that this wasn't just a nice-to-have but a bare necessity, though it would be a much less uphill battle when you have a tool that can do it with a lot less effort, making the cost/benefit tradeoff a lot more appealing when the cost is so much lower. But a lot of programmers of the time would make even larger messes even more quickly with AIs happy to do so if you didn't give them some guidance on how to use it. They would, of course, figure it out eventually, since "they" are also "us", and we collectively figured this out without AIs helping us along. But boy oh boy would there be some messes made first. I think some element of the problem is that, yes, programming was once a wild and wooly frontier of cowboys and crazy people doing crazy things. But one step at a time, the field has grown up, and a lot of people haven't noticed and still have this "cowboy programmer" idea in their mind. I don't know exactly when you might want to say the field became a real engineering field, with its own practices based on the local cost/benefit tradeoffs and its own procedures and its own "bare minimum for competence" standards. That partially depends on your own definitions. Some people who want to put the "bare minimum" at something like "uses dependent types and carries proofs for every line of code" might say we're not there yet, but you can always set the bar higher. But I think a lot of people have not looked around and realized that, yeah, actually, we have crossed that bar. Personally I put it around a decade ago. But I think we're there. We can stop wringing our hands about not being "real engineers" and stop looking over at what the "real engineers" do. We have better solutions for our problems then any amount of copying what they do could give us, just like they can't just lift our practices and apply it to their work because it doesn't fit their world. It's gotten to the point where dropping what we've got in hand now and trying to jam some other "real engineering" discipline's tools in would be a rather substantial regression. We can chill out a bit. We can also be glad that all the calls to try to systematize the field so it would be "real engineering" didn't go and lock in the 2006 idea of what "good software engineering" is so that we got stuck to it and we couldn't progress to where we are today. Two years ago I would have said maybe such an effort could do something useful, but then AI came along and overturned the apple cart and now, once again, I would be very suspicious of any attempt to lock in July 2026 practices as The One Correct Way To Write Software For The Next 100 Years.
beej71 3mo ago
I'm willing to change the name in order to not have this discussion. :) Luckily now I'm simply a "computer science instructor", though many argue what I teach is "software engineering"... Doh!
figassis 3mo ago
Also, Software engineering is engineering. Not all software if built through engineering. I'd say today almost zero software is built this way. Figure it out as you go is not engineering. But I'm sure at NASA people are doing real software engineering.

50 points by abrbhat 3mo ago

SideburnsOfDoom 3mo ago

> 429 Too Many Requests This is definably not engineering.

abrbhat 3mo ago
The link is from Internet Archive. The original post was on geocities which has long been dead.

threethirtytwo 3mo ago

>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.

whateverboat 3mo ago
Also person month is a very solid limitation.
baq 3mo ago
> software engineering does not involve mathematical modeling it absolutely can, approximately nobody was doing that because it was insanely expensive. if we narrow down the definitions, modern static typing (where modern means universally accepted nowadays) is a form of mathematical modeling and proof construction that software does what it says it does. the economic calculation is changing extremely rapidly now with LLMs though. some of my software is now proved to be correct at some levels, e.g. I heavily (that is, LLMs I pilot) use TLA+ for tricky but nowhere near foundational distributed systems work (as in, I don't work on core S3, but do distributed transaction stuff).
- threethirtytwo 3mo ago
  Yeah if you read further I mention the exceptions. Generally speaking though we don't do mathematical modeling. Basic Type checking is as far as we typically go.
abrbhat 3mo ago
> Anything that exists in reality and is observable by definition is tightly bound by the laws of physics and chemistry. Software is too. Agreed. If I have to guess, the relevant fields in physics for software engineering would be quantum mechanics and thermodynamics. Of course, we don't see any direct relation as of now but it feel it should be important to determine the physical basis of software. The basis of software cannot be just math. It has to be physics.
bob1029 3mo ago
> Computer science is neither about computers nor is it a science. https://youtu.be/-J_xL4IGhJA https://youtu.be/-J_xL4IGhJA
AnimalMuppet 3mo ago
> > 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. No. Software is only loosely bound by physics and chemistry. Sure, the bounds exist - they're real - but most software, most of the time, does not bump into them much at all. But > > An engineer's model must be tightly bound to the laws of physics and chemistry. is also wrong. This is using a pre-software definition of engineering to try to define software engineering. It would be like trying to use a pre-Faraday definition of physics to define microwave engineering.

SideburnsOfDoom 3mo ago

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.davefarley.net/?p=352 https://www.goodreads.com/en/book/show/57345270-modern-software-engineering https://www.goodreads.com/en/book/show/57345270-modern-softw... https://productdeveloper.net/modern-software-engineering/ https://productdeveloper.net/modern-software-engineering/

TomOwens 3mo ago
Dave Farley's book is really good, and I'd highly recommend it. However, I do have an issue with his focus on applying science in the definition, even though it doesn't come across in his final conclusions. In the history of engineering, that's a relatively new development. It started, to some extent, in Europe in the 1700s, but it really took off in the 1920s and exploded in the United States after World War II (1940s-1950s). It culminated with the Report of the Committee on Evaluation of Engineering Education (the Grinter Report) in the mid-1950s. This isn't to say that science isn't important to engineering, since it absolutely is. Science provides knowledge used to better understand the world being changed by engineering. But there are also plenty of examples of engineering going ahead of science - the steam engine, the airplane, generative AI. We didn't fully understand the governing rules before the technology existed. Any definition of engineering needs to be broader. Ferguson (Engineering and the Mind's Eye), Florman (several works, but primarily The Existential Pleasures of Engineering), and Vincenti (What Engineers Know and How They Know It) all explore ways in which engineering can't rely on science alone. I think Koen (Discussion of the Method) puts it best, where the application of science is one heuristic that engineers may choose to draw upon.
- skydhash 3mo ago
  > However, I do have an issue with his focus on applying science in the definition, even though it doesn't come across in his final conclusions I don’t think it’s about science. It’s about the scientific method. From wikipedia The scientific method is an empirical method for acquiring knowledge through careful observation, rigorous skepticism, hypothesis testing, and experimental validation You don’t have to have a full theory or model to follow. You also can follow your intuition and use your creativity. You just have to carefully compare your results to your goal.

eth0up 3mo ago

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.

magarnicle 3mo ago

If only there were "real" engineers who could answer this question... https://www.hillelwayne.com/tags/crossover-project/ https://www.hillelwayne.com/tags/crossover-project/

cognitiveinline 3mo ago

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.

andy99 3mo ago
Engineering is a regulated term, afaik that’s what underlies the debate, it’s not about whether English has changed.
- mfer 3mo ago
  Engineering is not a regulated term everywhere.
  - GroksBarnacles 3mo ago
    It many countries it actually is, if you call yourself an engineer professionally without a license you can be heavily fined. Canada, Germany, France..
    - stymaar 3mo ago
      I don't think you can be fined in France for that. Though I think you'll be fired without compensation or unemployment benefits.
  - analog31 3mo ago
    In the US, professional licensure is left to the states, and most states have some form of licensing for engineers along with reciprocity for transferring a license from one state to another. Commonly, engineers have an "industrial exemption" if they work for a company that makes a product rather than offering engineering services directly to the public (such as a civil or structural engineer might do). I've held an "engineer" title at my day job from time to time, though I'm not an engineer and have no engineering degree. Only a couple of engineers at my work site have licenses. On the other hand, my brother in law was a nuclear engineer, and all of the engineers at the power plant were licensed. One thing you'll notice is that small companies that do contract or consulting work will call themselves "research" or "technology" rather than using the E word on their web page.

ed_elliott_asc 3mo ago

Why don’t we just call ourselves programmers and save this semi-regular debate!

CuriouslyC 3mo ago
Because that diminishes the work people do. A programmer takes logic and encodes it for a machine to execute. Being an engineer suggests solving problems and defining logic. The engineer title is apt in my opinion, because if you look at construction as a parallel, the architect designs the shape of the building, engineers determine how to build it so it doesn't collapse, and builders actually make it real. Programming is like digital building, the architecture and implementation details are both separate.
IAmBroom 3mo ago
Centuries of accumulated respect for the word "engineer", implying a specialization that can't be simply replaced with other skill sets. That is: prestige and therefore economic incentives.
ryandvm 3mo ago
Because I haven't been allowed to program for 6 months. Now I'm just an AI manager.
apple4ever 3mo ago
Because we believe engineering fits more closely.

rkozik1989 3mo ago

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.

CivBase 3mo ago

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.

bitexploder 3mo ago
I just work here. The label is for everyone else :)
jeddy3 3mo ago
Software developer?
- CuriouslyC 3mo ago
  If someone told me I couldn't call myself an engineer and instead I had to call myself a software developer, I'd turn around and tell them I just forgot all my theoretical computer science, and of course we can do a bubble sort on the multi-terabyte database, LOL.
skydhash 3mo ago
I think engineering is about norms and regulations. Creating solutions for problems can be done in a very wide spectrum, but the restricted window where you try to respect books of rules is what people call engineering.

okamiueru 3mo ago

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.

rbanffy 3mo ago

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”.

Fire-Dragon-DoL 3mo ago
Did you just call me poet sorcerer? Lol Cool analogies
- rbanffy 3mo ago
  My wife says I’m a computer charmer. I prefer to say I write executable poetry that moves the hearts of machines.
  - Fire-Dragon-DoL 3mo ago
    Ah! Unfortunately machine aren't prone to cuddles,lol
summa_tech 3mo ago
Right! I think a lot of people, who have not done a lot of "things you can kick" engineering, have a very romantic view of it. Especially the relationship with whoever is nominally setting the goals of the project. The physics works perfectly, of course. But physics is only a third of the constraint in engineering. The other two thirds are project goals and convention. Project goals are horribly underspecified, every time. It's incredibly rare to be given a project that is completely constrained on that side, and if you do get one, most of the time it's physically impossible to achieve. This is because the people who write those specifications not doing engineering, they're doing marketing or sales or just had a cool idea. Sometimes that can even be the engineer themselves :-) So it's up to the engineer to fill in the gap, and they do it with experience and a sense of aesthetics, of sorts. Convention is what constrains the physical possibilities of engineering to the practical. Yes, you can build anything and make it work, possibly even better than what everyone else builds. But you will have to invent and construct a lot of new technologies before you can build your perfect mousetrap. So, you settle on standard components and build a decent one instead. But this introduces a gap between physics and engineering, too. A bit of no-man's land that you can reach into to produce truly great results. But it's up to the engineer to know when it's worth it.

deleted 3mo ago

[deleted]

tdb7893 3mo ago

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 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.

bee_rider 3mo ago
Engineers use software and inevitably some will improve the software as they use it. I’d draw a distinction between engineering using software, and engineering the software itself, though. It becomes a bit blurry—I’d say using the Matlab command line is not necessarily software engineering, it’s using a tool for engineering that happens to be made of software. But you can also write your own Matlab code, so if we want to say there’s software engineering I guess there’s no reason it couldn’t be done in that environment. IMO, I’ve never been all that concerned as to whether the “engineer” label should apply to me (coming from an engineering education but mostly looking at software). It’s more about having a professional obligation than any great feats of skill anyway, and since an obligation is mostly just felt in your head, you can give it to yourself.

defmacr0 3mo ago

The article is "not even wrong". Most of the argument just circles around an inconsistent definition of what "real world" means. > Remember "imaginary numbers" from algebra? You could do funky stuff with them like take the square root of negative nine. Imaginary numbers are generally useless for the physical world that we experience. However, they turned out to be very useful in the field of electronics. More specifically, they had predictive power in the field of electronics. Using imaginary number math, one can predict behavior of electrons and the accuracy of such predictions in models can be measured. Like here, I struggle to understand what the point is. Is predicting the behavior of electronics "useless for the physical world we experience"? And that's ignoring the author's apparent ignorance of all the other ways in which complex numbers are useful in the physical world besides taking negative numbers' square roots.

aregue 3mo ago

I had a professor that used to say that engineering is modelling problems with a set of differential equations and finding a numerical approximation to the solution. No differential equation ==> Not engineering.

FatherOfCurses 3mo ago

Engineering is a profession where individuals are certified by a governing body and required to maintain that certification through continuing education. The reason for that certification is because failure to follow the principles of the governing body can lead to injury or death, or to a lesser degree significant costs. Given all the ways that software can have those same significant impacts, I believe that there should be some sort of level at which software developers are called engineers. However, I believe that designation should come with all the professional oversight that other engineering disciplines have.

sys_64738 3mo ago
Real engineers have to sign off their professional reputation against what they do. Software licences say that the software is provided as-is with zero liability. Calling software developers as "engineers" is just not the same thing.

jerf 3mo ago

Yes, it is: https://jerf.org/iri/post/2026/programming_is_engineering/ https://jerf.org/iri/post/2026/programming_is_engineering/ That said, there's been a lot of changes since this was written that was relevant to the point being made, so I'm not sure I necessarily disagree with the article as written at the time. If we take the metric I used in that blog post and asked "what if we were handed current-gen AI in 2006, how well would it do?", my answer is that it would do noticeably less well. This is even more true if we instead go back to 2006 and use current hardware tech but have to train on what was available at the time. Source control was fairly popular at that point, although it hadn't penetrated everywhere yet. I don't recall a lot of curmudgeons complaining that Real Programmers Don't Need Source Control at the time, it was pretty obvious that a record of what was happening in the source code base was useful. However, IIRC, in the open source world we'd mostly have been on cvs. svn was well into the process of eating it but still had a ways to go yet. "git" had just barely been born and it would be years before it was a serious force. Beyond that, a lot of stuff I take for granted in the engineering domain was either immature or non-existent. I was on the cutting edge bothering everyone about the importance of unit testing. There were communities like Perl that had a strong culture of it and a lot of support, but still a lot of people who would use it without that and a lot of language communities without the culture. A lot of projects banged together their own haphazard solutions, but a lot of projects just went without. No devops. Metrics was something I'd never really heard of. Logs probably went to your disk and the idea of unifying them was just at the beginning. QA was much less established. QA was generally not a team that would be using much automation, it would be all hand testing. CI/CD wasn't a term yet because hardly anyone had anything even resembling it. Bug trackers were still pretty bad and not everyone used them. I'm sure a lot of people will go "yeah, but I was programming in 2006 and I had all those things", because there were certainly teams that did. Go look at Microsoft Window's dev team, for instance, and they'd have most of what we'd consider a modern development stack, albeit with some quirks we'd find odd. It's not that none of this existed, it's that it wasn't considered just the baseline for a project to be minimally competent the way it is now. And rather than the programmers having an abundance of free options and an even larger abundance of paid and hosted options, to the point it's hard to poke through them all, they're using one of a few very expensive vendors or they put it together themselves. Introducing an AI into a code base of tens or hundreds of thousands of lines, with minimal testing, trained on the code practices of that era... a modern programmer could probably still work with it. You could tell it about unit testing and it would know what you meant, it would probably just need to be prompted to do it. You could put together unified logging with some work. You could solve the problems... but your solutions would basically be putting in those 2026 guard rails. You'd have the same uphill battle convincing people of the time that this wasn't just a nice-to-have but a bare necessity, though it would be a much less uphill battle when you have a tool that can do it with a lot less effort, making the cost/benefit tradeoff a lot more appealing when the cost is so much lower. But a lot of programmers of the time would make even larger messes even more quickly with AIs happy to do so if you didn't give them some guidance on how to use it. They would, of course, figure it out eventually, since "they" are also "us", and we collectively figured this out without AIs helping us along. But boy oh boy would there be some messes made first. I think some element of the problem is that, yes, programming was once a wild and wooly frontier of cowboys and crazy people doing crazy things. But one step at a time, the field has grown up, and a lot of people haven't noticed and still have this "cowboy programmer" idea in their mind. I don't know exactly when you might want to say the field became a real engineering field, with its own practices based on the local cost/benefit tradeoffs and its own procedures and its own "bare minimum for competence" standards. That partially depends on your own definitions. Some people who want to put the "bare minimum" at something like "uses dependent types and carries proofs for every line of code" might say we're not there yet, but you can always set the bar higher. But I think a lot of people have not looked around and realized that, yeah, actually, we have crossed that bar. Personally I put it around a decade ago. But I think we're there. We can stop wringing our hands about not being "real engineers" and stop looking over at what the "real engineers" do. We have better solutions for our problems then any amount of copying what they do could give us, just like they can't just lift our practices and apply it to their work because it doesn't fit their world. It's gotten to the point where dropping what we've got in hand now and trying to jam some other "real engineering" discipline's tools in would be a rather substantial regression. We can chill out a bit. We can also be glad that all the calls to try to systematize the field so it would be "real engineering" didn't go and lock in the 2006 idea of what "good software engineering" is so that we got stuck to it and we couldn't progress to where we are today. Two years ago I would have said maybe such an effort could do something useful, but then AI came along and overturned the apple cart and now, once again, I would be very suspicious of any attempt to lock in July 2026 practices as The One Correct Way To Write Software For The Next 100 Years.

beej71 3mo ago

I'm willing to change the name in order to not have this discussion. :) Luckily now I'm simply a "computer science instructor", though many argue what I teach is "software engineering"... Doh!

figassis 3mo ago

Also, Software engineering is engineering. Not all software if built through engineering. I'd say today almost zero software is built this way. Figure it out as you go is not engineering. But I'm sure at NASA people are doing real software engineering.