- 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.
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
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.
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].
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.
I think that there's probably a difference between "attacking a problem to achieve progress in the utility of something" and just slapping together an app that brings literally nothing new to the table.
Making a birdhouse isn't engineering, creating a new type of dwelling for birds might be.
>>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
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.
That doesn’t make sense to me. If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering. What’s the difference?
> then the failure modes and legal consequences are the same as traditional engineering
Exactly my point! Because the failure mode is the same we should have the same guardrails in place for both.
The design and construction of a bridge is independently inspected and verified. The design and implementation of software in a car is not independently inspected and verified. I argue that because the failure modes are the same, we should change the latter to match the former.
The design of a bridge must carry the signature of an individual licensed engineer who is personally liable. The design of software in a car is functionally anonymous. I argue that because the failure modes are the same, we should change the latter to match the former.
The design of software in a car is held to similar standards as the hardware in a car, as one of the people who sign off on it (and not a PE). The software often is independently inspected and verified as part of homologation.
Adding a scapegoat engineer wouldn't do anything meaningful except ruin one dude's career when something happens because
1) automotive manufacturers don't fall under engineering firm regulations
2) one person cannot have meaningful technical oversight over the scope of a vehicle, and
3) there is no software PE accreditation process in the US.
They've been true for over a century at this point though. Since I assume you aren't complaining about every vehicle ever produced not being signed by PEs, what is it about software that you think it should require a PE stamp when hardware should not?
> They've been true for over a century at this point though.
The duration of the status quo doesn’t feel at all relevant to my argument.
> what is it about software that you think it should require a PE stamp when hardware should not?
Any profession of system design whose failure mode is “people die” would better serve a culture that abhors preventable deaths if governed by the same licensure, liability, professional ethics and independent verification used by electrical and structural engineering. I don’t make any distinction between hardware and software, but this article happens to be about software, so that’s what we’re discussing.
> If a software bug can cause a death, like in a car, then the failure modes and legal consequences are the same as traditional engineering.
They are not even remotely. A business may have to pay out a settlement, and failure may attract the interest of regulators (say, the NTSB if it is a car or airplane or the FDA if it's a medical device), but nobody is going to lose their license to practice "software engineering" nor face professional sanction even if there is professional malpractice.
The fact that nobody has gone to jail or had their ability to work in software revoked as a consequence of the 737 Max incident is proof that they are not even remotely similar. Had an aerospace engineer certified a physical part the same way that the software engineers certified that software they most certainly would have been on the hook individually for massive damages and would never work in industry again - both because they'd have been named and shamed in the investigation and because likely their license to practice engineering would have been revoked.
The difference is that as a civil engineer, when I put my stamp on something and become Engineer of Record, I am personally liable for defects in my engineering, in perpetuity, no matter who I go on to work for later.
I can lose my personal wealth, freedom, license and livelihood if it's particularly egregious.
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.
I didn't realize it was time to drag this old chestnut out of storage. Nothing like dusting off a decades long flame war. I'm sure everyone will come to an agreement this time.
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.
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.
The problem with this question is that, if it's not engineering, what is it? A better question is motivated by studying the history of chemistry and its progenitor, alchemy. That is: is software development alchemy or chemistry?
Software development is alchemy. Just like alchemy, software dev is not standardized, everyone has their own idiosyncratic naming systems, classifications and rules-of-thumb. Like alchemists, software engineers are often jealous of their proprietary knowledge. Just like alchemists, they are admired, feared and loathed for having secret knowledge. And just like alchemists, you have to be exceedingly brilliant to work in such a chaotic field and get anything done.
So, what changed alchemy into chemistry, and what will be the analog to that in software? Arguably the change started with notion of conservation of mass and energy, and the development of the periodic table (thanks to Lavoisier and Mendeleev, respectively). As for what that analog is for software, first we need a characterization of the field. With alchemy and chemistry both, it's essentially mixing stuff together, heating and cooling it, and seeing what happens. But what is it for software?
First, software engineering is not computer science. Computer science is a tiny subset of software engineering. In daily practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).
I'd characterize software engineering as the set of solutions to a boundary value problem[0] described as "a set of interacting screens with behaviors pleasing to humans". The current solutions to this problem have been idiosyncratically defined by resource constraints that relaxed exponentially over time[1], and characterized by elements discovered at random, by necessity: e.g. kernels, processes, files, procedures, terminals, etc. In this analysis "language" functions as a kind of "coordinate system" as in physics[2][3], within which each of these elements are described, and within which elements are combined to make new elements, which eventually yield a solution to the boundary problem (which is termed "application"). There is some coorespondence with chemistry, in that we have "elements" which combine into higher-level structures, but we lack an analogy to "conservation of mass and energy". And our elements are still highly partitioned according to coordinate system (although there have been several[4] heroic[5] attempts to unify them within a single framework.)
I don't particularly know what the standardization of software alchemy into software engineering will look like, but I'm certain that this analysis, or something similar to it, is the first steps in the right direction. Personally, I look forward to the day we can shed the considerable weight of our alchemical origins!
I think you need to review the history of science. Alchemy did indeed yield many things of practical value, all of which were systematized and rolled into chemistry. And besides, the fact that an alchemy of one kind might be more valuable than an alchemy of another doesn't invalidate my point. It just means that once our field changes phase, it will be even MORE valuable.
Definitely an interesting analogy, I find it uncharitable towards the state of software engineering though. Whereas alchemy/chemistry had to unlock a model of the microscopic world based on observation of the macro world we were born into, software engineering was the entire creation of a new world that we built from the ground up. It’s not that we don’t have a sufficient understanding to build great and precise software works, it’s just that the macro space is so large and unconstrained without the physical limitations that keep problem spaces of physical sciences more tractable and comprehensible.
I do agree SWE is still early days and will develop a lot, but I don’t think it will coalesce the way you’re suggesting though because we’ll keep dreaming up new things to do with arbitrary data and logic.
> Computer science is a tiny subset of software engineering. In practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live.
I agree with that...
> (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).
...but not so much with that! Computer science is immensely useful in real world work: it helps to be able to look at a task and recognise it as an application of a few, general theorems, say in the field of graph theory or distributed systems, and let that knowledge guide your implementation. Just knowing that the problem you're facing is mathematically undecidable tells you more than weeks of experimentation would, for instance. Perhaps it's often a mistake to ask about it as an interview question, but it's not a mistake to familiarise oneself with the theory.
The issues are twofold with the relationship between computer science and software engineering.
Firstly, typical computer science courses are simply not advanced enough. At the pace of a typical university education, one would need to get to doctorate level before being able to reliably make novel developments in a given field, but that probably won't sound like a good investment of time and money when one could be earning significantly above-average salaries in industry even without the education. I personally believe that making more intensive courses available would be ideal for a large number of otherwise very competent programmers who are limited by their lack of academic computer science education.
Secondly, computers are too luxurious of an environment to necessitate rigour! If you're building a shelving unit, you won't need to perform complicated calculations to measure stress-strain curves or cantilevering forces. The tolerances are so wide that you can get bolt together about any planks of wood and make a piece of furniture that is mechanically adequate. Does that make cabinet-making alchemy? I think it makes it more like craftsmanship, but it's definitely not engineering! Likewise, most computer applications always have CPU cycles to spare, data storage on tap and flexible timing requirements, so innovation only really happens at the limits of the technology: hyperscale applications, safety-critical or embedded software.
I still think it's slightly unfair to say that software development is alchemy, when it is to me more like a well-established but rather conservative craft, which is only occasionally pushed into academic study and engineering rigour when the stakes are high enough.
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.
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.
I agree that for people who do that type of work, it's engineering
For a typical fullstack dev building views, CRUDs, and simple DB schemas, less so
And you're probably right that most SWEs don't deal with math-adjacent things.
---
And just to be clear, none of what I'm saying is a value-statement on the types of work different "software engineers" do. It's just a question of categories, which I view as separate from utility
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 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.
One of my favorite arguments in this topic is when 'Real Engineers' say "If my part fails, someone could DIE!"...to the Facebook/IG/TicTok Engineer whose role in Social media drives suicides across the world.
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.
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.
> 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'd say with classic engineering, mother nature wrote the OS, so across all the disciplines there is a common shared experience of dealing with Reality OS. Which is eminently present in every step of work.
In SWE, we figured out how to build a VM in Reality OS that runs our own custom environment. All the headache and complexity is there, but it is of a different lineage.
Every wall powered device on the North American grid is connected to the same circuit. And even within circuit design, it's all designed piecemeal with inputs and outputs.
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.
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.
If it were real engineering, we would be able to safely run arbitrary code, just like you can safely plug anything into an outlet and not take down the grid.
There are some safeties built in (fuses/circuit breakers) but ultimately it’s not so different than safeguards in software. Hence why the electric grid often has issues.
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.
All engineering is making something complex and functional, so yes, absolutely. Of course, there is software that is neither of these things, but there's also fallen trees across rivers that serve as bridges and eventually erode.
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.
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.
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.
107 comments
[ 4.0 ms ] story [ 97.2 ms ] thread- 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.
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.
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
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.
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...
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.
I think even if rigor required it's low you can think of a good solution for a problem, feature or product
Making a birdhouse isn't engineering, creating a new type of dwelling for birds might be.
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
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.
Exactly my point! Because the failure mode is the same we should have the same guardrails in place for both.
The design and construction of a bridge is independently inspected and verified. The design and implementation of software in a car is not independently inspected and verified. I argue that because the failure modes are the same, we should change the latter to match the former.
The design of a bridge must carry the signature of an individual licensed engineer who is personally liable. The design of software in a car is functionally anonymous. I argue that because the failure modes are the same, we should change the latter to match the former.
Adding a scapegoat engineer wouldn't do anything meaningful except ruin one dude's career when something happens because
1) automotive manufacturers don't fall under engineering firm regulations
2) one person cannot have meaningful technical oversight over the scope of a vehicle, and
3) there is no software PE accreditation process in the US.
The duration of the status quo doesn’t feel at all relevant to my argument.
> what is it about software that you think it should require a PE stamp when hardware should not?
Any profession of system design whose failure mode is “people die” would better serve a culture that abhors preventable deaths if governed by the same licensure, liability, professional ethics and independent verification used by electrical and structural engineering. I don’t make any distinction between hardware and software, but this article happens to be about software, so that’s what we’re discussing.
They are not even remotely. A business may have to pay out a settlement, and failure may attract the interest of regulators (say, the NTSB if it is a car or airplane or the FDA if it's a medical device), but nobody is going to lose their license to practice "software engineering" nor face professional sanction even if there is professional malpractice.
The fact that nobody has gone to jail or had their ability to work in software revoked as a consequence of the 737 Max incident is proof that they are not even remotely similar. Had an aerospace engineer certified a physical part the same way that the software engineers certified that software they most certainly would have been on the hook individually for massive damages and would never work in industry again - both because they'd have been named and shamed in the investigation and because likely their license to practice engineering would have been revoked.
The difference is that as a civil engineer, when I put my stamp on something and become Engineer of Record, I am personally liable for defects in my engineering, in perpetuity, no matter who I go on to work for later.
I can lose my personal wealth, freedom, license and livelihood if it's particularly egregious.
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 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.
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.
Software development is alchemy. Just like alchemy, software dev is not standardized, everyone has their own idiosyncratic naming systems, classifications and rules-of-thumb. Like alchemists, software engineers are often jealous of their proprietary knowledge. Just like alchemists, they are admired, feared and loathed for having secret knowledge. And just like alchemists, you have to be exceedingly brilliant to work in such a chaotic field and get anything done.
So, what changed alchemy into chemistry, and what will be the analog to that in software? Arguably the change started with notion of conservation of mass and energy, and the development of the periodic table (thanks to Lavoisier and Mendeleev, respectively). As for what that analog is for software, first we need a characterization of the field. With alchemy and chemistry both, it's essentially mixing stuff together, heating and cooling it, and seeing what happens. But what is it for software?
First, software engineering is not computer science. Computer science is a tiny subset of software engineering. In daily practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live. (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).
I'd characterize software engineering as the set of solutions to a boundary value problem[0] described as "a set of interacting screens with behaviors pleasing to humans". The current solutions to this problem have been idiosyncratically defined by resource constraints that relaxed exponentially over time[1], and characterized by elements discovered at random, by necessity: e.g. kernels, processes, files, procedures, terminals, etc. In this analysis "language" functions as a kind of "coordinate system" as in physics[2][3], within which each of these elements are described, and within which elements are combined to make new elements, which eventually yield a solution to the boundary problem (which is termed "application"). There is some coorespondence with chemistry, in that we have "elements" which combine into higher-level structures, but we lack an analogy to "conservation of mass and energy". And our elements are still highly partitioned according to coordinate system (although there have been several[4] heroic[5] attempts to unify them within a single framework.)
I don't particularly know what the standardization of software alchemy into software engineering will look like, but I'm certain that this analysis, or something similar to it, is the first steps in the right direction. Personally, I look forward to the day we can shed the considerable weight of our alchemical origins!
0 - https://en.wikipedia.org/wiki/Boundary_value_problem
1 - https://en.wikipedia.org/wiki/Moore's_law
2 - https://en.wikipedia.org/wiki/Coordinate_system
3 - https://www.rosettacode.org/wiki/Rosetta_Code - the same problem is solved in many languages. For applications: https://todomvc.com/
4 - zeroonetwothree ↗ The entire world runs on software now. It seems absurd to equate it with alchemy which produced no practical value. simpaticoder ↗ I think you need to review the history of science. Alchemy did indeed yield many things of practical value, all of which were systematized and rolled into chemistry. And besides, the fact that an alchemy of one kind might be more valuable than an alchemy of another doesn't invalidate my point. It just means that once our field changes phase, it will be even MORE valuable. dasil003 ↗ Definitely an interesting analogy, I find it uncharitable towards the state of software engineering though. Whereas alchemy/chemistry had to unlock a model of the microscopic world based on observation of the macro world we were born into, software engineering was the entire creation of a new world that we built from the ground up. It’s not that we don’t have a sufficient understanding to build great and precise software works, it’s just that the macro space is so large and unconstrained without the physical limitations that keep problem spaces of physical sciences more tractable and comprehensible. seabass-labrax ↗ > Computer science is a tiny subset of software engineering. In practice, almost all of computer science is encapsulated in a few, tiny standard libraries - the places where bubble-sorts and hash maps live.
I do agree SWE is still early days and will develop a lot, but I don’t think it will coalesce the way you’re suggesting though because we’ll keep dreaming up new things to do with arbitrary data and logic.
I agree with that...
> (This mistake is consistent, and leads to "leet code" style interview questions which are irrelevant to actual work).
...but not so much with that! Computer science is immensely useful in real world work: it helps to be able to look at a task and recognise it as an application of a few, general theorems, say in the field of graph theory or distributed systems, and let that knowledge guide your implementation. Just knowing that the problem you're facing is mathematically undecidable tells you more than weeks of experimentation would, for instance. Perhaps it's often a mistake to ask about it as an interview question, but it's not a mistake to familiarise oneself with the theory.
The issues are twofold with the relationship between computer science and software engineering.
Firstly, typical computer science courses are simply not advanced enough. At the pace of a typical university education, one would need to get to doctorate level before being able to reliably make novel developments in a given field, but that probably won't sound like a good investment of time and money when one could be earning significantly above-average salaries in industry even without the education. I personally believe that making more intensive courses available would be ideal for a large number of otherwise very competent programmers who are limited by their lack of academic computer science education.
Secondly, computers are too luxurious of an environment to necessitate rigour! If you're building a shelving unit, you won't need to perform complicated calculations to measure stress-strain curves or cantilevering forces. The tolerances are so wide that you can get bolt together about any planks of wood and make a piece of furniture that is mechanically adequate. Does that make cabinet-making alchemy? I think it makes it more like craftsmanship, but it's definitely not engineering! Likewise, most computer applications always have CPU cycles to spare, data storage on tap and flexible timing requirements, so innovation only really happens at the limits of the technology: hyperscale applications, safety-critical or embedded software.
I still think it's slightly unfair to say that software development is alchemy, when it is to me more like a well-established but rather conservative craft, which is only occasionally pushed into academic study and engineering rigour when the stakes are high enough.
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.
Hardware interlocks were replaced with software. And people died.
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
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.
For a typical fullstack dev building views, CRUDs, and simple DB schemas, less so
And you're probably right that most SWEs don't deal with math-adjacent things.
---
And just to be clear, none of what I'm saying is a value-statement on the types of work different "software engineers" do. It's just a question of categories, which I view as separate from utility
Aka they take fundamental theoretical concepts and given the physical constraints we have from the existing computing systems they come up with viable solutions.
I also don't think most people who call themselves a "software engineer" fit that description though. My guess would be less than 10%?
“a person who designs, builds, or maintains engines, machines, or public works.”
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.
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.
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?
In SWE, we figured out how to build a VM in Reality OS that runs our own custom environment. All the headache and complexity is there, but it is of a different lineage.
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.
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.
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.
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.
To me, the answer to the first is obviously no and the second is obviously yes.
https://ncees.org/ncees-discontinuing-pe-software-engineerin...