Electrical Engineer who can write messy but functional code in C and Python, but mainly deals with analog circuits at work.
Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts. And you get the extremely rapid prototyping and scaling that comes with that. (A "single line of code" equivalent error in a production analog circuit can take months to fix and years to distribute)
In a way it feels "unfair" because the fuckery of mother nature and immovable boundaries of physics is largely (and normally completely) cut out of the equation. Imagine having to write code where every variable is a fuzzy range as opposed to a fixed value, it would put a huge clamp on designs.
However,
The intellectual savings from not having to deal with non-linearities and errant physical effects, is largely just shifted into increased overall complexity that all exists in a different realm. So maximum logical thinking and intellect is still demanded.
I think the divide really comes from the difference in space in which the "engineering" is happening. Conventional engineers are dealing directly with nature trying it's best to constantly break your design. And I think there is a degree of comradery that comes with that. Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity.
> Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts.
I get where you are coming from, but man it is very apparent that you haven't had to write device drivers. Hardware is BUGGY and the OS is full of workarounds to make things work well enough most of the time.
EDIT: And now that I think about it, the same is true of any piece of software that interacts with other software components. Your own code ends up full of workarounds to address problems in your external dependencies.
> Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity
That resonates. You could say that in other branches of engineering complexity is a consequence of natural entropy, whereas in software complexity is largely self-inflicted. Did I get it right?
I think computer scientists work in a “parallel universe of perfect logic” but sadly I strongly disagree that the vast majority of software engineers get that privilege.
IMO, contemporary SWE involves a lot of black box treatment, learning complex systems on the fly, and untested large code bases. All of that leads to similar dynamics as more direct physical dynamics in other engineering disciplines do: unexplained behavior, doing things by spec, debugging by process of elimination, etc.
And that’s before mentioning the direct problem of device and network issues; I understand this to be a certainty for those doing things on a global scale.
While it might seem that software runs in an idealized domain free of conventional physics, that's only because operating systems and processors try to provide a "padded cell" in which software can live. But it's a leaky abstraction; for instance, the time it takes to read one byte of memory can vary depending on whether the processor has it on the L1 cache, or has to read it from the DRAM, and even there, it might depend on whether the memory row is open or not, it might get delayed by the DRAM refresh cycle, and so on, and we're not even talking about the case where it's been paged out and the operating system has to read the memory page from the disk. There's a lot of "non-linearities and errant physical effects" there, and as a sibling comment mentioned, the speed of light is still very relevant.
And that's before considering mindfuckery like Spectre and its friends, in which you can, through a careful observation of some timings, watch the effect of an operation which didn't happen, won't happen, can't happen, and sometimes from code which doesn't even exist.
One of the things I think hardware should adopt from software is modular debuggability of system components. I'm a software guy building a display board with a battery management system. I'm building the bms as a pluggable component on the display to make my development easier and the end unit more iterable.
In many ways SWE is like real engineering but with some major differences. I could use the classic example "we aren't building bridges" but that's too simplistic. I think the biggest difference between us and the rest of engineering is the "method of delivery" and how that affects the other processes.
What I mean is imagine if a car company found a defect with their cars, they would have to issue a recall and update their vehicles, a long an expensive process. The key difference is with SWE, we can just push an update and have the thing fixed, there are many possible scenarios here but overall even if you had to push a patch to customers that are running in an air-gapped env, even that would be easier than a traditional recall in engineering. For me this single fact changes the entire dynamic of SWE compared to traditional engineering.
In traditional engineering you can't simply put up a bridge that would support 500 cars and say "oh we'll update it to support 5000 cars down the road", but you can totally do that with SWE application that can only support X number of users at the start but plans to scale up to support more. This thinking of "we can address this down the road" affects practically every decision in SWE compared to traditional engineering outside of specific cases.
Every engineer deals with constraints and finds ways around those constraints. SWE has a set of constrains that is very very different from virtually all other engineering disciplines, and for that reason you get the constant question of whether SWE is even real engineering.
What makes “real engineering” the correct paradigm (and legal framework) for a profession isn’t the method of delivery, it’s the failure mode and how that aligns with cultural values.
In the simplest example: if you ship a car with a bug in its RTOS, people could die. It doesn't matter how easy it is to update. As a culture we’re generally opposed to preventable deaths. In other professions we have set up a regime of legal liability and professional licensing as guardrails and incentives to prevent that failure mode. We should treat software engineering the same, at a minimum in applications where lives are at stake.
Other non-lethal failure modes should also be considered (Experian, anyone?). We may have culturally decided by default or accident that data leaks are no big deal. If we actually did think they were important, it would make sense to have licensing and liability frameworks to reflect that.
The fact that software has fewer practical constraints than building structures is an excuse masquerading as a reason for not having even the most basic controls in place.
>>you can't simply put up a bridge that would support 500 cars and say "oh we'll update it to support 5000 cars down the road"
In that case the requirement changed, it might require some extra support or upgrades to the bridge, if not we have to build the bridge all over again.
Similar in SWE, the requirement can change, if you planned a small MYSQL database to hold 2 Stores transactions and then "oh well we will need to support 2000 Stores Transactions" you might try upgrade the server or start from zero on a AWS cloud instance that keep up.
In SWE you still have the big decisions than can impact people and budget, a bridge can collapse, so the autopilot software can make the car crash
As a counter to your first example, I once had software deployed in some U.S. embassies in some not so great parts of the world. The machines the software lived on were air-gapped and on computers built specifically not to allow external connections (different keyboard/mouse connectors, no USB, no CD).
To deploy an update required a human, some long flights, and replacement parts. While it's not common, I think it would still break that definition of what is/isn't an engineer.
For me, it comes down to the level of rigor required. I think developing avionics software is probably engineering whereas building an phone app to view/share pictures of cats likely isn't.
Isn't every company doing all they can to force their other engineering into software delivery paradigm?
The whole "seat warmers as a service" pops to mind
That's the whole idea of "Digital Engineering"
The former Acquisitions Chief for the US Air Force just announced that they got a contract to CERTIFY a plane for airworthiness before ever actually building one in real life [1].
Yeah, incidentally recall campaigns for some companies are the same for software as for hardware, think medical device. But the software is constructed in the same Agile way as anywhere else in fortune500 world.
Engineering, no matter where it is, is about reacting to costs and benefits. Software engineering has radically different costs and benefits than physical engineering. It would be inappropriate to blindly copy over the engineering practices from other fields without adapting to the huge changes on both the costs and benefits sides.
If other engineering fields had metaphorically similar costs and benefits to software, their procedures would look like ours. If they could flip a flag to change the color scheme on their hotel and push the "compile" button to tear down the entire previous hotel and build a new one in 30 seconds, they would not be using blueprints and carefully planning their every move. They'd incrementally build a structure just like we do, pre-existing libraries, iterative development, the whole thing. They don't not because this is not engineering, but because they can't. You can't afford to have an inspector come in at the end of their project and announce that the ceilings are 6 inches under code and the whole thing is condemned.
I find the occasional moon-struck love affair with other engineering disciplines and how they're doing real engineering and aren't they just so dreamy to be badly misplaced. They would be jealous of us, if they knew what we had. They're doing real engineering. We're doing real engineering. The people not doing real engineering are the ones who blindly copy inappropriate methodologies from other engineering disciplines, which is the engineering methodology equivalent of writing object oriented code in Haskell. Building a program like it's a skyscraper and we must plan our every line of code, which we can place only once, and it must be perfectly correct, six months in advance, is as inappropriate as trying to build a skyscraper through iterative development.
In electrical engineering, there is some iteration in development (board spins). But nowhere near the flexibility of software. That's why it's almost always better, imo, to turn a hardware problem into a software one.
- The blue print analogy is used a lot to argue why software engineering isn't real engineering. The reasoning goes like this: you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems. If only software engineering was that predictable. Of course with software, the process of creating the blue print is literally creating the software. The build step tends to be fully automated (compilation). Blue prints for your blue prints used to be a thing when we had waterfall. Creating a blue print for a bridge or a nuclear plant is similarly less predictable. Because that's where you have to do all your problem solving. That's why so many of these hard engineering projects go way over budget.
- SpaceX is using rapid iterations with rocket design. This is real engineering but they are also doing things that come directly from the agile world like not trying to design the entire rocket waterfall style, failing, and then spending another five years fixing the design. Instead they iterate rapidly, go through lots of prototypes and iteratively refine the rocket.
So, it's not that black and white. The process of creating good blueprints on a predictable schedule is not a solved problem. Also not in hard engineering projects. Using agile methodology and testing your blueprints in either simulated or real form helps.
>you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems
Which is hilarious, because nothing in the real world works that way. My BIL is a civil engineer and he spends tons of time traveling to sites to solve problems that pop up during implementation.
I didn't listen to the interviews but, as a pure software person I've observed the following:
1. Most software 'engineers' are more like technicians, plugging libraries into each other
2. A very small subset of software writers are in fact doing real engineering
I'm working with a semiconductor company at the moment, with traditionally trained engineers, many of whom are 25+ year vets from industry and academia. Semiconductor design makes most software 'engineering' look like children playing with safety scissors. In silicon, the bar to ship is nothing short of literal perfection. When's the last time you shipped a software project with 0 known bugs, spent tens of thousands of hours on testing (design verification), and improved on the best-yet-achieved-by-humans performance by 2x - 5x? Never? Same.
It seems to me the reason this question gets asked is due to the massive gulf between software and other engineering disciplines in terms of the level of rigor and correctness brought as table-stakes. As others have pointed out, software has the luxury of being able to hotfix bugs (correctness, and performance) after release. This has led to most of our industry being extremely sloppy, lazy, and frankly kind of embarrassing. Software shipped today is dramatically less efficient, more buggy, and sometimes even less useful than software shipped just 10 years ago, let alone 15 or 25.
I don't have a solution for this problem, but I hope we can one day hang the big-engineering-boys-and-girls, and, ship quality software again.
I'd like to say I fully agree with you, but I don't think this "perfection" you talk about is usually reached, not even in your exceptional domain: Remember the living lists of CPU errata! And retpoline, meltdown, spectre! God only knows how many of those are out there, unknown or actively exploited.
Hardware people are not the pinnacle of engineering correctness — that would go to people who do formal verification. Unfortunately not even mathematicians think the price is right.
> 1. Most software 'engineers' are more like technicians, plugging libraries into each other
You didn't mine, smelt, and manufacture the raw material yourself? Sorry, not an 'engineer', technician only. You're using other people's stuff to do your thing.
Most software development is not engineering. Engineering is about requirements, guarantees, and specifications.
When you engineer a bridge, there is a use case such as light vehicle traffic. That translates to a load requirement to achieve that goal. Your design must then guarantee that it fulfills that requirement.
Success and failure in this environment are defined and objective. Furthermore, you can largely rely on the guarantee being made; the correct operation is well-defined within some meaningful domain. Engineering turns the subjective qualities of a product into objective bars for success.
Specifications generalize this process by providing well-defined guarantees. These can then be used by another to fulfill their requirements.
Engineering rewards results, not efforts. It is about fitness of purpose, not best efforts. It is about success and failure, not how hard you tried.
My previous career was mechanical engineering. I was on track to be a licensed engineer in my country, I have a mechE masters degree.
Even in “traditional engineering” some people refer to certain tasks as “not real engineering”. Usually they are talking with their ego and wish it was the 70’s so they could be drafting with pencil.
Their opinion doesnt mean anything and is basically regressive.
So the idea of if any task is “real engineering” is just such a pointless debate.
Defining any activity as engineering or “not engineering” isn't useful.
Calling yourself a software engineer is fine as a job application tool, but needing to be seen as an “engineer” is just meaningless ego.
Ive seen this debate for over a decade at this point, some like to split developers vs engineers by some arbitrary standards, but honestly it doesnt and has never meant anything.
The problem is not if software engineers are engineers or not, the problem is with defining software itself, as an EE myself, I do software, we learned how to write programs even in assembly back in the school too, however, you have now (at that’s even before the AI LLM hype) a horde of people who call themselves “engineers” after attending a 3 weeks bootcamp in some front-end framework or library or some data analysis course, they will know how to import a library and repeat some known processes, they lack what every engineer should know, architecture design, I personally believe that if someone can convert an abstract idea into an applicable design, is in fact an engineer, software or not.
In the context of being an engineer - it's not. A real engineer's licence can be revoked due to misconduct, is issued by a governing body and carries some weight.
Software developers can call themselves engineers or even Code-Alchemists, but it carries zero weight.
Apparently, the National Council of Examiners for Engineering and Surveying (the board that regulates other engineering fields in the USA, such as civil engineering) used to offer a Professional Engineer (PE) exam for software engineering, but it was dropped in 2019 due to lack of participation and bad prospects for increased participation.
I think it’s worth separating the question of “do software engineers actually carry professional liability or have their designs independently reviewed” from the question of “is software development work sufficiently consequential and verifiable to warrant professional liability and certification requirements?"
To me, the answer to the first is obviously no and the second is obviously yes.
I think that is an argument for the term rather than against. A SWE SHOULD be held responsible for the things they make and the impacts it causes. Additionally, so should PMs and CEOs but heyyyy.
I guess the big issue is that it is easy to place blame in the case of a bridge failing...but much harder when a system products mass suicides.
I think what's actually fuzzier is the definition of "real" engineering, whatever the hell that is. I'm not discounting that specific practices within engineering have clear definitions, but there's no one consistent way to lump every one of those professions together and have a cohesive "you're in or you're out" definition.
I would say it depends on the specific role and project, but for most people who write code, likely not.
Coming from a mechanical engineering background, I understood "engineering" as the application of science for problem solving - or, put simply, applied science. Some examples:
1. When a civil engineer applies solid mechanics to select a cross beam.
2. When an electrical engineer applies E&M to design a circuit.
3. When a mechanical engineer applies heat transfer to analyze cooling patterns on a laptop.
Under this definition, most "SWE" work isn't engineering - if anything, it's closer to applied math and logic?
That said, definitions are only useful inasmuch as they allow us to make sense of the world and communicate with others, so I'm not sure this is the most useful question
You could consider it as applied science in that we are dealing with CPUs, we do benchmarks, we build models of things ... but this isn't work that everyone does.
I wouldn't call most SWE work close to applied math or logic. Very few people get to deal with things that are math-adjacent or do applied math in general. Many things are just .. plumbing data.
Not a CE myself, but computer engineers definitely consider physics in their solutions since they have to consider complexity, computational speed, memory restrictions, concurrency etc
Aka they take fundamental theoretical concepts and given the physical constraints we have from the existing computing systems they come up with viable solutions.
There is a big difference between the person that builds the skyscraper and the person that does the maintenance.
Most of us empty the trash and change the lightbulbs and think we are structural engineers. I'm ok with what I do, but I don't pretend I'm something I am not.
I've thought about this a lot as a dev. IMHO, no, and the main reason is a strong resistance to standardization: in OS platforms that we work on, software libraries to do basic things that we include, education credentials, and QA. We simply can't agree on a practical knowledge base as a profession that beyond the 1st and 2nd year CS fundamentals. There are some best practices that we've seem to coalesce around, but even those are somewhat ill-defined.
OTOH, I'd also be lying if I said that there weren't real world benefits to working a little more "fast and loose", and I'm at a point in my career where I can accept that the varying level of rigor and standardization in the more profitable software companies is the best balance in today's world, and I try to pick my battles.
But I don't think this is any more "engineering" than an MBA using spreadsheets and accounting statements to decide where to allocate human or capital resources to maximize profit. We just use a fancier set of tools and have a different domain to optimize.
And I know this doesn't reflect every dev job. But it sure does a heck of a lot of them.
When I wrote strictly software on computers, typically with a way to push fixes, I felt like it wasn’t really “real” engineering.
Then I wrote firmware for some devices that was fairly complex and the programming needed to be absolutely perfect to ensure various hardware issues (and product bugs/failures as a result) couldn’t happen.
You wind up creating remarkably stable and thoroughly tested code, both digitally and physically, and the end result is something incredibly precise due to rigorous design and execution both on the software and hardware sides.
That feels a lot more like engineering. I actually miss it a lot. I can’t help but bring a lot of what I learned to usual software development, but I find a lot of people dislike the same kind of rigour and precision. Like it’s in the way of getting things done, and fundamentally that’s all that counts.
I can see why pure software isn’t considered engineering as a result. The “we can push a fix” mentality can seriously undermine one’s care for the work as well as the overall design and testing practices.
In any case, I’d argue it can be engineering, but it often isn’t.
There are times that I feel like I’m doing engineering when I write software. Those are often the most fulfilling (and most frustrating) parts of my job. But most of the time what I’m doing is just putting things together or repairing things to achieve a goal - not figuring out anything new. I’d say I feel more like a construction worker for 80-90% of my workload.
well engineering is not project management , while engineers do a lot of project management, PM is not engineering
Waterfall and Agile is not Software engineering, I think software engineering is algorithm design, API design and anything design, coding and tooling in general
software project management is .. software business, not software engineering
The main difference is that software engineering is extremely tolerant of poor engineering standards and practices, relative to "traditional" engineering disciplines.
This allows many organizations to utilize software engineering skills without having any particular mentality towards engineering itself. Some businesses can be arranged such that the software development practice is much like an assembly line, reducing developers to assembly line workers. Some businesses actually use engineering skills and have an engineering mindset.
The fact that businesses can find success while having terrible or no engineering practice is an example of where software engineering differs from any sort of engineering of physical things. Mechanical, electrical, chemical, etc engineering does not have such a tolerance, they simply exhibit failure if so.
Funny post. I came from purely webdev software engineering to hardware engineering and let me tell you, it is an interesting coalescence of mechanical, electrical, and software engineering (both firmware and regular 'ol software).
I sit in on several different design reviews and it kills me how similar each engineer thinks even with such disparate differences between each discipline.
In terms of difficulty for my smoothbrain to comprehend from easiest to hardest to understand, I'd say it goes mechanical, software, electrical, and then firmware.
Like holy hell, firmware engineering is a dark art. Kudos to firmware engineers.
> 'd say it goes mechanical, software, electrical, and then firmware.
I think it’s about the mindset, like how some people enjoy doing numbers while others see it gibberish, personally I find embedded easier to work with, on the other hand, I still can’t fully comprehend React spaghetti.
I think it is best to drop all analogies to other disciplines (“it’s like a bridge but…”, “it’s like building a house but…”).
These analogies are oddly captivating even for those who are very experienced in software but do not have any experience in other problem domains.
I think that while such analogies provide some comfort, we are better off eschewing them completely. In software we need to focus on the actual “mess” in order to begin to draw useful conclusions.
At the end of the day, what is “real” anything? Isn’t this just a form of the “True Scotsman” logical fallacy?
[+] [-] Workaccount2|2 years ago|reply
Software has a magical property that other engineering disciplines do not: The engineering environment is ideal and fundamentally perfect. It's like building electronic circuits but only in the simulator that uses all idealized parts. And you get the extremely rapid prototyping and scaling that comes with that. (A "single line of code" equivalent error in a production analog circuit can take months to fix and years to distribute)
In a way it feels "unfair" because the fuckery of mother nature and immovable boundaries of physics is largely (and normally completely) cut out of the equation. Imagine having to write code where every variable is a fuzzy range as opposed to a fixed value, it would put a huge clamp on designs.
However,
The intellectual savings from not having to deal with non-linearities and errant physical effects, is largely just shifted into increased overall complexity that all exists in a different realm. So maximum logical thinking and intellect is still demanded.
I think the divide really comes from the difference in space in which the "engineering" is happening. Conventional engineers are dealing directly with nature trying it's best to constantly break your design. And I think there is a degree of comradery that comes with that. Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity.
[+] [-] david-gpu|2 years ago|reply
I get where you are coming from, but man it is very apparent that you haven't had to write device drivers. Hardware is BUGGY and the OS is full of workarounds to make things work well enough most of the time.
EDIT: And now that I think about it, the same is true of any piece of software that interacts with other software components. Your own code ends up full of workarounds to address problems in your external dependencies.
> Software guys, free form those chains and working in a parallel universe of perfect logic, instead are pushed to the absolute limits of complexity
That resonates. You could say that in other branches of engineering complexity is a consequence of natural entropy, whereas in software complexity is largely self-inflicted. Did I get it right?
[+] [-] bbor|2 years ago|reply
IMO, contemporary SWE involves a lot of black box treatment, learning complex systems on the fly, and untested large code bases. All of that leads to similar dynamics as more direct physical dynamics in other engineering disciplines do: unexplained behavior, doing things by spec, debugging by process of elimination, etc.
And that’s before mentioning the direct problem of device and network issues; I understand this to be a certainty for those doing things on a global scale.
[+] [-] cesarb|2 years ago|reply
And that's before considering mindfuckery like Spectre and its friends, in which you can, through a careful observation of some timings, watch the effect of an operation which didn't happen, won't happen, can't happen, and sometimes from code which doesn't even exist.
[+] [-] amelius|2 years ago|reply
[+] [-] christkv|2 years ago|reply
[+] [-] foooorsyth|2 years ago|reply
[+] [-] aswanson|2 years ago|reply
[+] [-] zeroonetwothree|2 years ago|reply
Moreover your software has to interact with that of everyone else ever. Imagine if every circuit you make has to connect to every previous circuit.
[+] [-] pineapple_guy|2 years ago|reply
[+] [-] Fire-Dragon-DoL|2 years ago|reply
[+] [-] PhilipRoman|2 years ago|reply
[+] [-] _fat_santa|2 years ago|reply
What I mean is imagine if a car company found a defect with their cars, they would have to issue a recall and update their vehicles, a long an expensive process. The key difference is with SWE, we can just push an update and have the thing fixed, there are many possible scenarios here but overall even if you had to push a patch to customers that are running in an air-gapped env, even that would be easier than a traditional recall in engineering. For me this single fact changes the entire dynamic of SWE compared to traditional engineering.
In traditional engineering you can't simply put up a bridge that would support 500 cars and say "oh we'll update it to support 5000 cars down the road", but you can totally do that with SWE application that can only support X number of users at the start but plans to scale up to support more. This thinking of "we can address this down the road" affects practically every decision in SWE compared to traditional engineering outside of specific cases.
Every engineer deals with constraints and finds ways around those constraints. SWE has a set of constrains that is very very different from virtually all other engineering disciplines, and for that reason you get the constant question of whether SWE is even real engineering.
[+] [-] velcrovan|2 years ago|reply
In the simplest example: if you ship a car with a bug in its RTOS, people could die. It doesn't matter how easy it is to update. As a culture we’re generally opposed to preventable deaths. In other professions we have set up a regime of legal liability and professional licensing as guardrails and incentives to prevent that failure mode. We should treat software engineering the same, at a minimum in applications where lives are at stake.
Other non-lethal failure modes should also be considered (Experian, anyone?). We may have culturally decided by default or accident that data leaks are no big deal. If we actually did think they were important, it would make sense to have licensing and liability frameworks to reflect that.
The fact that software has fewer practical constraints than building structures is an excuse masquerading as a reason for not having even the most basic controls in place.
[+] [-] lelima|2 years ago|reply
In that case the requirement changed, it might require some extra support or upgrades to the bridge, if not we have to build the bridge all over again.
Similar in SWE, the requirement can change, if you planned a small MYSQL database to hold 2 Stores transactions and then "oh well we will need to support 2000 Stores Transactions" you might try upgrade the server or start from zero on a AWS cloud instance that keep up.
In SWE you still have the big decisions than can impact people and budget, a bridge can collapse, so the autopilot software can make the car crash
[+] [-] mikecx|2 years ago|reply
To deploy an update required a human, some long flights, and replacement parts. While it's not common, I think it would still break that definition of what is/isn't an engineer.
For me, it comes down to the level of rigor required. I think developing avionics software is probably engineering whereas building an phone app to view/share pictures of cats likely isn't.
[+] [-] AndrewKemendo|2 years ago|reply
The whole "seat warmers as a service" pops to mind
That's the whole idea of "Digital Engineering"
The former Acquisitions Chief for the US Air Force just announced that they got a contract to CERTIFY a plane for airworthiness before ever actually building one in real life [1].
So yeah, it's happening
[1]https://www.istaridigital.com/press-releases/air-force-award...
[+] [-] _glass|2 years ago|reply
[+] [-] jerf|2 years ago|reply
If other engineering fields had metaphorically similar costs and benefits to software, their procedures would look like ours. If they could flip a flag to change the color scheme on their hotel and push the "compile" button to tear down the entire previous hotel and build a new one in 30 seconds, they would not be using blueprints and carefully planning their every move. They'd incrementally build a structure just like we do, pre-existing libraries, iterative development, the whole thing. They don't not because this is not engineering, but because they can't. You can't afford to have an inspector come in at the end of their project and announce that the ceilings are 6 inches under code and the whole thing is condemned.
I find the occasional moon-struck love affair with other engineering disciplines and how they're doing real engineering and aren't they just so dreamy to be badly misplaced. They would be jealous of us, if they knew what we had. They're doing real engineering. We're doing real engineering. The people not doing real engineering are the ones who blindly copy inappropriate methodologies from other engineering disciplines, which is the engineering methodology equivalent of writing object oriented code in Haskell. Building a program like it's a skyscraper and we must plan our every line of code, which we can place only once, and it must be perfectly correct, six months in advance, is as inappropriate as trying to build a skyscraper through iterative development.
[+] [-] aswanson|2 years ago|reply
[+] [-] jillesvangurp|2 years ago|reply
- The blue print analogy is used a lot to argue why software engineering isn't real engineering. The reasoning goes like this: you create a blueprint of something like a bridge and you don't start building the bridge until the blue print is done. Then the bridge building process is reasonably predictable and structured because you already solved all the problems. If only software engineering was that predictable. Of course with software, the process of creating the blue print is literally creating the software. The build step tends to be fully automated (compilation). Blue prints for your blue prints used to be a thing when we had waterfall. Creating a blue print for a bridge or a nuclear plant is similarly less predictable. Because that's where you have to do all your problem solving. That's why so many of these hard engineering projects go way over budget.
- SpaceX is using rapid iterations with rocket design. This is real engineering but they are also doing things that come directly from the agile world like not trying to design the entire rocket waterfall style, failing, and then spending another five years fixing the design. Instead they iterate rapidly, go through lots of prototypes and iteratively refine the rocket.
So, it's not that black and white. The process of creating good blueprints on a predictable schedule is not a solved problem. Also not in hard engineering projects. Using agile methodology and testing your blueprints in either simulated or real form helps.
[+] [-] 303uru|2 years ago|reply
Which is hilarious, because nothing in the real world works that way. My BIL is a civil engineer and he spends tons of time traveling to sites to solve problems that pop up during implementation.
[+] [-] jesse__|2 years ago|reply
I didn't listen to the interviews but, as a pure software person I've observed the following:
1. Most software 'engineers' are more like technicians, plugging libraries into each other
2. A very small subset of software writers are in fact doing real engineering
I'm working with a semiconductor company at the moment, with traditionally trained engineers, many of whom are 25+ year vets from industry and academia. Semiconductor design makes most software 'engineering' look like children playing with safety scissors. In silicon, the bar to ship is nothing short of literal perfection. When's the last time you shipped a software project with 0 known bugs, spent tens of thousands of hours on testing (design verification), and improved on the best-yet-achieved-by-humans performance by 2x - 5x? Never? Same.
It seems to me the reason this question gets asked is due to the massive gulf between software and other engineering disciplines in terms of the level of rigor and correctness brought as table-stakes. As others have pointed out, software has the luxury of being able to hotfix bugs (correctness, and performance) after release. This has led to most of our industry being extremely sloppy, lazy, and frankly kind of embarrassing. Software shipped today is dramatically less efficient, more buggy, and sometimes even less useful than software shipped just 10 years ago, let alone 15 or 25.
I don't have a solution for this problem, but I hope we can one day hang the big-engineering-boys-and-girls, and, ship quality software again.
[+] [-] Traubenfuchs|2 years ago|reply
[+] [-] threatofrain|2 years ago|reply
[+] [-] BackBlast|2 years ago|reply
You didn't mine, smelt, and manufacture the raw material yourself? Sorry, not an 'engineer', technician only. You're using other people's stuff to do your thing.
[+] [-] Veserv|2 years ago|reply
When you engineer a bridge, there is a use case such as light vehicle traffic. That translates to a load requirement to achieve that goal. Your design must then guarantee that it fulfills that requirement.
Success and failure in this environment are defined and objective. Furthermore, you can largely rely on the guarantee being made; the correct operation is well-defined within some meaningful domain. Engineering turns the subjective qualities of a product into objective bars for success.
Specifications generalize this process by providing well-defined guarantees. These can then be used by another to fulfill their requirements.
Engineering rewards results, not efforts. It is about fitness of purpose, not best efforts. It is about success and failure, not how hard you tried.
[+] [-] kingkongjaffa|2 years ago|reply
Even in “traditional engineering” some people refer to certain tasks as “not real engineering”. Usually they are talking with their ego and wish it was the 70’s so they could be drafting with pencil.
Their opinion doesnt mean anything and is basically regressive.
So the idea of if any task is “real engineering” is just such a pointless debate.
Defining any activity as engineering or “not engineering” isn't useful.
Calling yourself a software engineer is fine as a job application tool, but needing to be seen as an “engineer” is just meaningless ego.
Ive seen this debate for over a decade at this point, some like to split developers vs engineers by some arbitrary standards, but honestly it doesnt and has never meant anything.
[+] [-] tamimio|2 years ago|reply
[+] [-] trey-jones|2 years ago|reply
Software Engineering is real engineering.
Far fewer software engineers exist than software developers who call themselves software engineers.
I have never called myself a software engineer.
Like most titles of prestige, "engineer" has been massively devalued of late by the constant marketing machine.
[+] [-] baxuz|2 years ago|reply
In the context of being an engineer - it's not. A real engineer's licence can be revoked due to misconduct, is issued by a governing body and carries some weight.
Software developers can call themselves engineers or even Code-Alchemists, but it carries zero weight.
[+] [-] funnyflywheel|2 years ago|reply
https://ncees.org/ncees-discontinuing-pe-software-engineerin...
[+] [-] velcrovan|2 years ago|reply
To me, the answer to the first is obviously no and the second is obviously yes.
[+] [-] agloe_dreams|2 years ago|reply
[+] [-] zeroonetwothree|2 years ago|reply
[+] [-] jehb|2 years ago|reply
I think what's actually fuzzier is the definition of "real" engineering, whatever the hell that is. I'm not discounting that specific practices within engineering have clear definitions, but there's no one consistent way to lump every one of those professions together and have a cohesive "you're in or you're out" definition.
[+] [-] Antoniocl|2 years ago|reply
Coming from a mechanical engineering background, I understood "engineering" as the application of science for problem solving - or, put simply, applied science. Some examples:
1. When a civil engineer applies solid mechanics to select a cross beam. 2. When an electrical engineer applies E&M to design a circuit. 3. When a mechanical engineer applies heat transfer to analyze cooling patterns on a laptop.
Under this definition, most "SWE" work isn't engineering - if anything, it's closer to applied math and logic?
That said, definitions are only useful inasmuch as they allow us to make sense of the world and communicate with others, so I'm not sure this is the most useful question
[+] [-] PartiallyTyped|2 years ago|reply
I wouldn't call most SWE work close to applied math or logic. Very few people get to deal with things that are math-adjacent or do applied math in general. Many things are just .. plumbing data.
[+] [-] whatever1|2 years ago|reply
Aka they take fundamental theoretical concepts and given the physical constraints we have from the existing computing systems they come up with viable solutions.
[+] [-] hermannj314|2 years ago|reply
Most of us empty the trash and change the lightbulbs and think we are structural engineers. I'm ok with what I do, but I don't pretend I'm something I am not.
[+] [-] lr4444lr|2 years ago|reply
OTOH, I'd also be lying if I said that there weren't real world benefits to working a little more "fast and loose", and I'm at a point in my career where I can accept that the varying level of rigor and standardization in the more profitable software companies is the best balance in today's world, and I try to pick my battles.
But I don't think this is any more "engineering" than an MBA using spreadsheets and accounting statements to decide where to allocate human or capital resources to maximize profit. We just use a fancier set of tools and have a different domain to optimize.
And I know this doesn't reflect every dev job. But it sure does a heck of a lot of them.
[+] [-] steve_adams_86|2 years ago|reply
Then I wrote firmware for some devices that was fairly complex and the programming needed to be absolutely perfect to ensure various hardware issues (and product bugs/failures as a result) couldn’t happen.
You wind up creating remarkably stable and thoroughly tested code, both digitally and physically, and the end result is something incredibly precise due to rigorous design and execution both on the software and hardware sides.
That feels a lot more like engineering. I actually miss it a lot. I can’t help but bring a lot of what I learned to usual software development, but I find a lot of people dislike the same kind of rigour and precision. Like it’s in the way of getting things done, and fundamentally that’s all that counts.
I can see why pure software isn’t considered engineering as a result. The “we can push a fix” mentality can seriously undermine one’s care for the work as well as the overall design and testing practices.
In any case, I’d argue it can be engineering, but it often isn’t.
[+] [-] devmor|2 years ago|reply
[+] [-] systems|2 years ago|reply
Waterfall and Agile is not Software engineering, I think software engineering is algorithm design, API design and anything design, coding and tooling in general
software project management is .. software business, not software engineering
[+] [-] stratigos|2 years ago|reply
This allows many organizations to utilize software engineering skills without having any particular mentality towards engineering itself. Some businesses can be arranged such that the software development practice is much like an assembly line, reducing developers to assembly line workers. Some businesses actually use engineering skills and have an engineering mindset.
The fact that businesses can find success while having terrible or no engineering practice is an example of where software engineering differs from any sort of engineering of physical things. Mechanical, electrical, chemical, etc engineering does not have such a tolerance, they simply exhibit failure if so.
[+] [-] freitzkriesler2|2 years ago|reply
I sit in on several different design reviews and it kills me how similar each engineer thinks even with such disparate differences between each discipline.
In terms of difficulty for my smoothbrain to comprehend from easiest to hardest to understand, I'd say it goes mechanical, software, electrical, and then firmware.
Like holy hell, firmware engineering is a dark art. Kudos to firmware engineers.
[+] [-] tamimio|2 years ago|reply
I think it’s about the mindset, like how some people enjoy doing numbers while others see it gibberish, personally I find embedded easier to work with, on the other hand, I still can’t fully comprehend React spaghetti.
[+] [-] osigurdson|2 years ago|reply
These analogies are oddly captivating even for those who are very experienced in software but do not have any experience in other problem domains.
I think that while such analogies provide some comfort, we are better off eschewing them completely. In software we need to focus on the actual “mess” in order to begin to draw useful conclusions.
At the end of the day, what is “real” anything? Isn’t this just a form of the “True Scotsman” logical fallacy?