4 ms·

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 simplisti

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.

AndrewKemendo 3y ago
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]. So yeah, it's happening [1]https://www.istaridigital.com/press-releases/air-force-awards-istari-digital-19m-contract-to-develop-worlds-first-digitally-certified-airplane https://www.istaridigital.com/press-releases/air-force-award...
mikecx 3y ago
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.
- lelima 3y ago
  What about day-to-day items, like well engineered wallet or water bottle, it's still engineering but the rigor still can be low, right? I think even if rigor required it's low you can think of a good solution for a problem, feature or product
  - tiznow 3y ago
    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.
velcrovan 3y ago
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.
- davedx 3y ago
  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?
  - velcrovan 3y ago
    > 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.
    - AlotOfReading 3y ago
lelima 3y ago
>>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
_glass 3y ago
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.

AndrewKemendo 3y ago

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]. So yeah, it's happening [1]https://www.istaridigital.com/press-releases/air-force-awards-istari-digital-19m-contract-to-develop-worlds-first-digitally-certified-airplane https://www.istaridigital.com/press-releases/air-force-award...

mikecx 3y ago

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.

lelima 3y ago
What about day-to-day items, like well engineered wallet or water bottle, it's still engineering but the rigor still can be low, right? I think even if rigor required it's low you can think of a good solution for a problem, feature or product
- tiznow 3y ago
  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.

velcrovan 3y ago

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.

davedx 3y ago
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?
- velcrovan 3y ago
  > 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.
  - AlotOfReading 3y ago

lelima 3y ago

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

_glass 3y ago

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.