13 ms·

I come from an aerospace engineering background (did structural engineering on commercial aircraft that were in the design and approval stages) and am in softwa

I come from an aerospace engineering background (did structural engineering on commercial aircraft that were in the design and approval stages) and am in software now (games). I've had two different takes on this. Neither is perfect. Would appreciate comments on them. (a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0] (b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1] [0] If software is engineering, then it's the only engineering discipline I'm aware of in which the participants are regularly expected to produce deliverables they don't fully understand. What do I mean by that? Well, if we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. If as a structural engineer I had delivered a final draft of an analysis document which showed that I didn't fully understand the part and how it would perform, my boss would not have been pleased. Most software bugs are treated more casually than that, so we clearly have a tolerance for delivering work that we don't fully understand. You might take issue with the idea that I "fully understood" a structural part. Fair. When I calculated the strength of a beam in a thrust reverser I didn't understand the individual molecular interactions, I didn't need to know if the metal was of a body-centered cubic crystal structure, etc. But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use. [1] This feels like the more flawed of the two proposals, because I expect EEs can do this. Control systems folks can definitely do this, and I would absolutely call them engineers.

netizen-936824 5y ago
>When I calculated the strength of a beam in a thrust reverser I didn't understand the individual molecular interactions, I didn't need to know if the metal was of a body-centered cubic crystal structure, etc. But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use. While I fully agree with almost everything in your post, this sounds an awful lot like an abstraction to me. Perhaps the different between creating software and engineering based on the physical sciences is the degree in which the abstractions are understood and rigorous. Perhaps software engineering is simply in its infancy and may eventually lead to more rigorous designs with less or no bugs in the future?
- aozgaa 5y ago
  In software, the range of correct operation (eg: maximum web server load with response time under x ms) is commonly unspecified and omitted. The strength of the beam gives a conservative estimate of its capabilities. Still a model/abstraction, but one with boundaries.
- Dma54rhs 5y ago
  I think there are bigger guarantees and checks the beam works as it's specified so the next engineer can continue. Google was using in production (firebase cli) the notorious trick the js developer played us other week. I doubt the other fields would rely on some random developer from Australia who has had a colorful past to provide the beam for structural engineer. And there's definetly more testing from all sort of parties they work om real life as advertised. Then again no one is offering free open source beams and you can't since you need materials not just one time drawings of an idea.
  - netizen-936824 5y ago
    The beams may not be open source but the calculations are
    - Ruthalas 5y ago
      If the beam is in a critical application, it may have provenance, or a material history, for similar purposes.
- Scramblejams 5y ago
  The difference (if any) between simplification and abstraction is the subject of some debate!
garettmd 5y ago
Point a seems more related to the "culture" surrounding modern engineering than it does a prerequisite for the discipline itself. Looking at how SpaceX engineers produce things looks totally different (from my outside perspective) from how a civil engineer sitting behind a desk would sign off on designs. Engineers at SpaceX seem to be more accepting of failure and have the "move fast, break things" mindset that most traditional engineers don't have.
- LegitShady 5y ago
  engineers at spacex are unlikely to go to jail because one of their designs blew up, but most engineers who design bridges or buildings dont have that luxury. Move fast, break things, pay for it with someone's life, lose your professional accreditation and maybe your freedom. Maybe they're playing similar but different games rather than playing the same game differently.
  - camtarn 5y ago
    As the article says: "bridges and buildings" engineering isn't even representative of all of civil engineering, let alone the entirety of the engineering profession. Also, not all engineers are even professionally accredited. I'd wager that the vast majority of engineers would not go to jail if their design failed.
jolux 5y ago
> Well, if we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. I don't think this is really incompatible with some of what Hillel gets at in his post with regards to professionalism and quality. I think it's possible for software engineers to have much higher confidence in what sorts of bugs their solutions do and do not contain, but the practice is mostly tilted towards velocity over catching every last bug. Because not all bugs are the same and not all requirements are equally important. Robust software systems are supposed to be built to minimize the impact of bugs in individual components where possible, with defensive programming techniques and such. > I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative I think this is a better candidate for a key difference than your other suggestions. We don't have a lot of good ways to apply conservative simplifying assumptions once software gets to a certain scale. We have abstractions, but where they are imperfect, any missed detail is a possible integration flaw.
- Scramblejams 5y ago
  Does this imply that the more complicated a stack gets, the less engineering can be done, and it devolves into something else?
  - jolux 5y ago
    Maybe? The problems definitely change. So much of software engineering is about managing complexity well. I haven't worked on sufficiently large projects or in sufficiently large organizations to tell you how exactly how it changes, I just know that it's different from talking to people who work at Google and Amazon and so on.
tester756 5y ago
Software is built on 150 layers that change incredibly often new cpus, changes to OS, core libs, frameworks, runtimes, vms, language libraries, new protocols, other hardware the dynamic here is way too big
chunky1994 5y ago
I think the difference in [0] is your input variable space is much smaller for "traditional" engineering disciplines. To grossly simplify: ME? You need tolerances for a specific amount of force (in different directions.) EE? You need tolerances for specific amounts of current passed through a circuit. With software your inputs are tremendously varied, because user input is not as well-formed as in any other engineering disciplines. In fact we deliberately try to find ways to input things that are not supposed to be inputs by designers of systems (i.e hacking things). If "hacking" bridges was a thing, it would be something like people trying to see if they can diffuse a thermite solution into the rock-face instead of driving a car over it, and I'm not sure any structural engineer has planned for that scenario.
steve76 5y ago
>(a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering A software bug means you can't drag and drop, or have to wait to import your contacts. An engineering risk means the hood of the car decapitates you above 30 mph, or the diesel fumes give everyone cancer. >(b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering. Everything's rated. You open a catalog from a supplier. If there's any question, go up in size. A lot is skids now. There are also trade associations. Dust settles. Products turn from novel invention into utility. Existing capacity is built around one thing a shop does right, especially the knowledge from the workers. Software is much harder. Go. Just go. Get it done. Get it out. Who cares if it's awful code. We need to make money now. Engineering is the applied science. Applied means you use it. You don't create it. If you do create it by chance, it's not your responsibility. Ma Bell didn't go into the business of the Big Bang when they discovered cosmic background radiation. Their job was telephones. Science means consistent observations regardless of the environment. Everyone thinks of scientists as people in lab coats. Nothing like that. Lot's of reading. Software is much more focused on engineering. In other disciplines you are a cashier at a grocery store. Software is much more like Menlo Park. You have a fixed commodity in server cost and bandwidth. Add value to it however you can.
bopbeepboop 5y ago
The problem is that “software” is as broad as “aerospace” or “construction”. Some aerospace things are highly engineered — airplane, rocket ships, etc; some things aren’t — kites, paper airplanes, etc; and some things are in-between, like gliders or hot air balloons. You get the same in buildings — which range from sheds to houses to skyscrapers. Also, the end of [0] and your discussion of your usage of routine abstractions to solve problems makes me wonder if you consider your own job to be (b)-type engineering.
- Scramblejams 5y ago
  I do not consider what I do now to be engineering. I'm responsible for a product used by my whole studio and I try to be very careful and produce a high quality deliverable, but I do not think of it as engineering.
d--b 5y ago
The strength of a beam is an atomic calculation. A software engineer should fully understand a function that calculates the length of a string... How is a spaceship blowing up not a bug? These happen fairly frequently... Oh, and oil spills? Fukushima? Mines that collapse? Talking about games. The physical equivalent to video games is pinball machines. Anyone who has played these can tell that the ball sometimes get stuck in weird places. This is exactly the equivalent of a software bug. Shouldn't the engineer have a total understanding of the machine so that the ball never gets stuck? You know, maybe games aren't so important that everything must be perfect. Also, I have a 2 year old. None of his toys have lasted more than 3 months. Literally 0 out of dozens. Isn't there a fortune to be made by engineering toys that can endure a kid's strength?
- cj 5y ago
  > This is exactly the equivalent of a software bug. Not really, because you can usually shake or tilt the pinball machine to set the ball free. > oil spills? Fukushima? Mines that collapse? These events happen (literally) once every few years or half decade. Software bugs happen (literally) billions of times per hour. (I’m not normally this pedantic, but felt the need since your comment comes across as knee jerk defensive without a whole lot of substance to work with)
  - d--b 5y ago
    > Not really, because you can usually shake or tilt the pinball machine to set the ball free. That's silly. A bug is an unintended behavior of the system. If you shipped a debugger with every video game, you'd probably be able to get yourself out of most bugs. > Software bugs happen (literally) billions of times per hour You're comparing things with different criticality. A bug that doesn't prevent you from doing your work is like a match that doesn't light up properly. These events happen all the time in the physical world. Bugs that shut down AWS for 24 hours tend to be less frequent... Let's just no enter in a debate about the frequency of "physical world bugs". Yes I admit it was a little knee jerk defensive.
  - MisterBastahrd 5y ago
    Yeah, oil spills occur because companies make conscious decisions to do the bare minimum to operate their pipelines. 500K gallons of crude spilled in Louisiana a few weeks back and nobody knew about it until cleanup efforts were underway. Why did the spill occur? It wasn't because the pipeline was engineered poorly. It was because the pipeline was not properly maintained. And people wonder why there are those who do not want an oil sands pipeline carved through an aquifer. Engineers don't work with infinite budgets and they usually are not the people who are making final decisions on either maintenance or implementation. Many of these failures occur because of budget constraints, time constraints, or decision makers who go against the recommendations of experts. IMO, the closest thing to a "software engineer" is a software architect. Everyone else is a craftsman.
skrtskrt 5y ago
> But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use. I am not sure how this is different from evaluating a library, database technology, or architecture, going through design review, learning properties of distributed systems (which have corresponding proofs by the way) to understand which properties you need to satisfy with a given solution, reading the documentation, viewing other open-source code that uses the technology, reading publications/testimonials from people and companies using it in productions, etc., etc., like we do. In particular "applying simplifying assumptions" - this is what we all have to do particularly in a distributed, cloud-computing world where you are essentially purchasing a conceptual primitive (like "virtual CPU" or "replicated block storage" and building on top of simplifying assumptions about how those work, because you can't walk up to the NAS rack and start hitting it with a hammer to see if the data can be recovered after, the same way you can't hit a steel beam with an actual hurricane to know what will happen. Although if I worked in the datacenter operations team for a cloud provider, I would absolutely hope to one day be able to test how we handle if I yank some plugs or hit the NAS rack with a hammer :)
- slingnow 5y ago
  It is absolutely wildly different. "Evaluating a library", "reading the documentation", etc., is absolutely NOT the same as basing your calculations on a hundred+ years of rigorously proven methods and deeper physical truths. How could you possibly infer that these are the same thing?
  - skrtskrt 5y ago
    software engineering is a younger discipline, we don’t have hundreds of years yet. You seem to think that our understanding of CPU operation or distributed systems isn’t based on physical truth and rigorous testing. Also a programming language or library or whatever has often been deployed by tens of thousands of organizations, across tens if millions of deployments, across trillions of discrete times the code path has been hit, and we know how it acts. That’s rigorous in its own way
yodsanklai 5y ago
> If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering. Totally disagree. Engineer = design and build things. Whether what you build has bugs or not is irrelevant to the definition. > If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering. All science is based on abstraction. Laws of physics used by aerospace engineers are abstractions of some more complex reality.
- Scramblejams 5y ago
  Is a child performing engineering when they resolve to build a tower of blocks and do so? If not, what distinguishes them from someone who is performing engineering? In your view, are simplification and abstraction the same thing? Or do they differ, and if so, in what way?
karaterobot 5y ago
Love this comment! > (a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0] This might arise from the different contexts without implying a different activity is taking place. Fixing bugs after launch is something you can do in software engineering, but can't really do in (say) structural engineering. If they could invisibly and safely swap out part of a bridge without stopping traffic, I'm betting they'd do it all the time! In software we can, and it makes sense to use this feature of digital products as part of the engineering process, in order to meet other requirements, like time and cost. (Whether it is overused or not is another question. I consider "good engineering" vs. "bad engineering" as distinct from "is engineering" or "is not engineering", ymmv)
varjag 5y ago
From my observations engineers in many disciplines would wing it all the time. Sometimes because of time/budget constraints, or simply because of lack of established methodology for certain corner cases. The scope of 'corner cases' also tended to be a lot larger in their disciplines' infancy: things like bridges (and yes, aircraft) were regularly built with assumptions pulled out of one's asses.
chiyc 5y ago
I appreciate you sharing your perspective! Mine's somewhat different having worked in another industry. I worked in semiconductor manufacturing as a process engineer. What counts as bug in that setting? It's completely expected to have defects in the final wafer. They go through a QA process. Some die can be repaired but others are trash. Die also get graded and low quality chips go to customers with less mission-critical needs. There's also a department dedicated to investigating early failures in defective product from customer returns. Personally, I viewed the product that I delivered as the wafers coming out of the steps I owned. High volume manufacturing is an ongoing process much like software development. As an individual process owner, I had metrics and goals to meet but my processes fit into a larger system I didn't fully understand. Process development happened by incremental changes much like software feature development. We would convert a small percentage of the production line with a new change at one step like you might use feature flags, but we sometimes had to rollback changes when something unexpected came up at yield or test. It might be more the nature of semiconductor manufacturing, but I view failures as part of the engineering process that comes up when we're pushing our tools and systems to new limits.
- Scramblejams 5y ago
  Good point, (a) doesn't hold up when you're dealing with the bleeding edge. Plenty of experimental airplanes, designed by highly credentialed engineers, fell out of the sky on the way to producing today's safety miracle of commercial aviation. Similar story (hopefully usually less deadly!) with other miracles, like modern semiconductors.
- pwr-electronics 5y ago
  When I worked in aerospace, there was a big, one-of-a-kind piece of metal where the fabricators had drilled a bunch of rivet holes in the wrong places. The structural engineers had to figure out if they could still use it. There's bugs in everything.
- torginus 5y ago
  I think a good software analogy for this would having a piece of multi-threaded code that accesses a shared resource using locks. There will probably be some waiting involved (analogous to defects). The engineer determine wha rate of waiting/working is acceptable, and if the software actually does perform like predicted. If it does not, as in the wait(defect) rate is higher, it might indicate a genuine bug in the system (like locks not being released in a timely manner), or a failure of planning.
dataflow 5y ago
How about this one: (c) If your project assumes the underlying device/system will behave exactly as it is told to, then you might be in a discipline that is distinct from engineering. This means "engineering" would include some software projects (like fault-tolerant system design), but exclude many others (like most desktop/mobile/web apps, perhaps with components like databases being exceptions). My rationale for this is that, best as I can tell, traditional engineering is (for the lack of a better phrase) about "taming the real world"—which doesn't always behave the way you tell it to, because it's inherently uncertain, failure-prone, and impossible to model exactly. So if your task is dealing with that, then you're doing engineering. Whereas if your main problem is coming up with the correct specification—but you assume it will be executed faithfully—then it's not really engineering per se, but something else (not sure if we have a name for it). Thoughts?
- Scramblejams 5y ago
  Intriguing! I'll have to let that percolate...
  - dataflow 5y ago
    I haven't fully figured out the implications to be honest. Some are more intuitive than others. For example, it would mean (some?) financial engineering is a misnomer ;) but it would also suggest that designing digital circuits is only engineering in certain cases, like high-speed cases where you have to make the design robust to extraneous analog effects. For what it's worth, I think it somewhat aligns somewhat with your point about abstractions.
    - Scramblejams 5y ago
      I appreciate the focus on abstractions. I'm unenthusiastic about giving up on (b), because when you've got a discipline where anybody can reach for any old terrible abstraction and stand some unholy monstrosity up that actually seems to work okay, I have a difficult time wanting to call it engineering. And I am fully in favor of financial engineering not being engineering. :-)
austincheney 5y ago
> What do I mean by that? My go to example every time is DOM. Out of the software developers I have encountered either online, during employment, or in person maybe 1 out of 50 who actively touch the DOM understand it well enough to have talks about it without wetting the bed. That's pretty tragic because the standard methods in most common use are about 23 years old (DOM Level 2) and take about 2 hours to learn.
908B64B197 5y ago
There's as many definitions of engineering as there are jurisdictions. Someone joked at some point that designing a PCB is real engineering (solidly into EE territory). Chip design as well (designing an ASIC is indeed generally considered to be EE). But replace that ASIC with a microcontroller and firmware and suddenly the firmware writer is no longer an engineer, despite the part having the same spec as the ASIC it replaces. Misplace one of these microcontrollers with the correct firmware on it in the wrong bin and it might even end-up on the same board the ASIC was supposed to go. And nobody would notice a thing. > If we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. In the embedded world that's more true than in "general purpose software" as the problem space is often better defined. There are also Realtime OSs that offer hard guarantees in terms of execution time and memory consumptions (or at least will have a hard cap on the upper bounds). It is possible to develop software that’s extremely predictable and has runtime measured in years. But it’s costly and takes time. > so we clearly have a tolerance for delivering work that we don't fully understand. Yes, when non-critical. You'll see it too with "silent upgrades" of physical products over their lifetime. Some of them are to correct non-critical flaws discovered over time. This tolerance has increased a lot over time as the cost of update has lowered (keep in mind not that long ago OS updates shipped as physical media!). And the cost of shipping bad (non-critical) software isn't the same as shipping defective products (think about the costs of a physical product recall). That allows a level of acceptable risk that’s alien to most other engineering disciplines. From the article: > In Canada you can't even call yourself a Software Engineer unless you're accredited! How much of that is the licensing body trying to squeeze a few dollars here and there? Do they actually enforce those rules? Would it be enforceable (if you can't define it properly, first amendment should apply...).
fphhotchips 5y ago
Isn't aerospace engineering the field that gave us pitot tubes that froze up at high altitude? > well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use. Isn't even this "reaching for abstractions"? I would argue that software engineering has two factors that result in higher bug counts: the lack of consequence, and the youth of the field. Lack of consequence shows up in errors in other fields, too. How many times has a civil engineer created an intersection that doesn't drain properly, or a curb that was slightly too high? Youth of the field shows up in other engineering fields also. See: pitot tubes, above.
spc476 5y ago
Somehow, the first Tacoma Narrows Bridge comes to mind. Carefully engineered, it still fell apart in a stiff breeze (fortunately, no one was killed).
Ericson2314 5y ago
> (b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1] Yeah my experience is trad engineers don't believe in nice things, haha. That's the difference. Just look at how moribund hardware is with a lack of open source tools compared to software.
torginus 5y ago
I think a key defining trait of engineering is the necessity of having a correct, precise model of the domain you are working in, so that you can solve multifaceted problems with the minimum possible resources. A typical non-engineering characteristic of software is the widespread acceptance of techniques/libraries that claim to make development easier at the cost of increased(outsourced) complexity and efficiency. I think a design technique that (allegedly) allowed you to spend half the time in a CAD software, but the resulting part would be less sturdy and more expensive to make wouldn't be exactly popular. Yet this is the bread and butter of software engineering, and since waste can be arbitrarily big, directly results in Wirth's law, with software consuming the extra resources and regressing to barely acceptable performance. Imo, one of the places when real engineering happens in the software world is video games. Here, there are actual constraints are very tight - one has to simulate a believable world, display 60 frames of meticulously calculated graphics on a clockwork cadence, synchronize players over an unreliable network in real-time, and so on and so forth. And do these things on cheap console hardware whose designers often favored raw performance over ease of use, sometimes to extreme degree, like the PS3. I'm pretty sure I barely scratched the surface. Yet it's commonplace to see chat applications crawl to a halt (Teams) and use enormous resources, while having a fluid UI in a game that just happens to run flawlessly beside a fully rendered 3D game world is considered the price of admission, not some technical feat.
zild3d 5y ago
Also a previous engineer (Systems & radar engineer on DoD projects like missile defense, avionics, etc) and now software engineer. Definitely disagree on both points. > (a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0] Every system has bugs. If you aren't expecting, controlling for them, and implementing measures to reduce their impact and likelihood - you might be in a discipline that is distinct from engineering. Why else would redundancy be a critical requirement in just about any mission critical systems? > (b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1] Well in radar, missile defense, helicopter systems, it was all abstractions up and down the stack. Maybe the 1000 engineers working on these projects weren't all real engineers? You have to use abstractions if you want to do anything real. You are regularly using models, simulations, tools, integrating with other teams' systems/components which become abstractions.

netizen-936824 5y ago

>When I calculated the strength of a beam in a thrust reverser I didn't understand the individual molecular interactions, I didn't need to know if the metal was of a body-centered cubic crystal structure, etc. But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use. While I fully agree with almost everything in your post, this sounds an awful lot like an abstraction to me. Perhaps the different between creating software and engineering based on the physical sciences is the degree in which the abstractions are understood and rigorous. Perhaps software engineering is simply in its infancy and may eventually lead to more rigorous designs with less or no bugs in the future?

aozgaa 5y ago
In software, the range of correct operation (eg: maximum web server load with response time under x ms) is commonly unspecified and omitted. The strength of the beam gives a conservative estimate of its capabilities. Still a model/abstraction, but one with boundaries.
Dma54rhs 5y ago
I think there are bigger guarantees and checks the beam works as it's specified so the next engineer can continue. Google was using in production (firebase cli) the notorious trick the js developer played us other week. I doubt the other fields would rely on some random developer from Australia who has had a colorful past to provide the beam for structural engineer. And there's definetly more testing from all sort of parties they work om real life as advertised. Then again no one is offering free open source beams and you can't since you need materials not just one time drawings of an idea.
- netizen-936824 5y ago
  The beams may not be open source but the calculations are
  - Ruthalas 5y ago
    If the beam is in a critical application, it may have provenance, or a material history, for similar purposes.
Scramblejams 5y ago
The difference (if any) between simplification and abstraction is the subject of some debate!

garettmd 5y ago

Point a seems more related to the "culture" surrounding modern engineering than it does a prerequisite for the discipline itself. Looking at how SpaceX engineers produce things looks totally different (from my outside perspective) from how a civil engineer sitting behind a desk would sign off on designs. Engineers at SpaceX seem to be more accepting of failure and have the "move fast, break things" mindset that most traditional engineers don't have.

LegitShady 5y ago
engineers at spacex are unlikely to go to jail because one of their designs blew up, but most engineers who design bridges or buildings dont have that luxury. Move fast, break things, pay for it with someone's life, lose your professional accreditation and maybe your freedom. Maybe they're playing similar but different games rather than playing the same game differently.
- camtarn 5y ago
  As the article says: "bridges and buildings" engineering isn't even representative of all of civil engineering, let alone the entirety of the engineering profession. Also, not all engineers are even professionally accredited. I'd wager that the vast majority of engineers would not go to jail if their design failed.

jolux 5y ago

> Well, if we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. I don't think this is really incompatible with some of what Hillel gets at in his post with regards to professionalism and quality. I think it's possible for software engineers to have much higher confidence in what sorts of bugs their solutions do and do not contain, but the practice is mostly tilted towards velocity over catching every last bug. Because not all bugs are the same and not all requirements are equally important. Robust software systems are supposed to be built to minimize the impact of bugs in individual components where possible, with defensive programming techniques and such. > I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative I think this is a better candidate for a key difference than your other suggestions. We don't have a lot of good ways to apply conservative simplifying assumptions once software gets to a certain scale. We have abstractions, but where they are imperfect, any missed detail is a possible integration flaw.

Scramblejams 5y ago
Does this imply that the more complicated a stack gets, the less engineering can be done, and it devolves into something else?
- jolux 5y ago
  Maybe? The problems definitely change. So much of software engineering is about managing complexity well. I haven't worked on sufficiently large projects or in sufficiently large organizations to tell you how exactly how it changes, I just know that it's different from talking to people who work at Google and Amazon and so on.

tester756 5y ago

Software is built on 150 layers that change incredibly often new cpus, changes to OS, core libs, frameworks, runtimes, vms, language libraries, new protocols, other hardware the dynamic here is way too big

chunky1994 5y ago

I think the difference in [0] is your input variable space is much smaller for "traditional" engineering disciplines. To grossly simplify: ME? You need tolerances for a specific amount of force (in different directions.) EE? You need tolerances for specific amounts of current passed through a circuit. With software your inputs are tremendously varied, because user input is not as well-formed as in any other engineering disciplines. In fact we deliberately try to find ways to input things that are not supposed to be inputs by designers of systems (i.e hacking things). If "hacking" bridges was a thing, it would be something like people trying to see if they can diffuse a thermite solution into the rock-face instead of driving a car over it, and I'm not sure any structural engineer has planned for that scenario.

steve76 5y ago

>(a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering A software bug means you can't drag and drop, or have to wait to import your contacts. An engineering risk means the hood of the car decapitates you above 30 mph, or the diesel fumes give everyone cancer. >(b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering. Everything's rated. You open a catalog from a supplier. If there's any question, go up in size. A lot is skids now. There are also trade associations. Dust settles. Products turn from novel invention into utility. Existing capacity is built around one thing a shop does right, especially the knowledge from the workers. Software is much harder. Go. Just go. Get it done. Get it out. Who cares if it's awful code. We need to make money now. Engineering is the applied science. Applied means you use it. You don't create it. If you do create it by chance, it's not your responsibility. Ma Bell didn't go into the business of the Big Bang when they discovered cosmic background radiation. Their job was telephones. Science means consistent observations regardless of the environment. Everyone thinks of scientists as people in lab coats. Nothing like that. Lot's of reading. Software is much more focused on engineering. In other disciplines you are a cashier at a grocery store. Software is much more like Menlo Park. You have a fixed commodity in server cost and bandwidth. Add value to it however you can.

bopbeepboop 5y ago

The problem is that “software” is as broad as “aerospace” or “construction”. Some aerospace things are highly engineered — airplane, rocket ships, etc; some things aren’t — kites, paper airplanes, etc; and some things are in-between, like gliders or hot air balloons. You get the same in buildings — which range from sheds to houses to skyscrapers. Also, the end of [0] and your discussion of your usage of routine abstractions to solve problems makes me wonder if you consider your own job to be (b)-type engineering.

Scramblejams 5y ago
I do not consider what I do now to be engineering. I'm responsible for a product used by my whole studio and I try to be very careful and produce a high quality deliverable, but I do not think of it as engineering.

d--b 5y ago

The strength of a beam is an atomic calculation. A software engineer should fully understand a function that calculates the length of a string... How is a spaceship blowing up not a bug? These happen fairly frequently... Oh, and oil spills? Fukushima? Mines that collapse? Talking about games. The physical equivalent to video games is pinball machines. Anyone who has played these can tell that the ball sometimes get stuck in weird places. This is exactly the equivalent of a software bug. Shouldn't the engineer have a total understanding of the machine so that the ball never gets stuck? You know, maybe games aren't so important that everything must be perfect. Also, I have a 2 year old. None of his toys have lasted more than 3 months. Literally 0 out of dozens. Isn't there a fortune to be made by engineering toys that can endure a kid's strength?

cj 5y ago
> This is exactly the equivalent of a software bug. Not really, because you can usually shake or tilt the pinball machine to set the ball free. > oil spills? Fukushima? Mines that collapse? These events happen (literally) once every few years or half decade. Software bugs happen (literally) billions of times per hour. (I’m not normally this pedantic, but felt the need since your comment comes across as knee jerk defensive without a whole lot of substance to work with)
- d--b 5y ago
  > Not really, because you can usually shake or tilt the pinball machine to set the ball free. That's silly. A bug is an unintended behavior of the system. If you shipped a debugger with every video game, you'd probably be able to get yourself out of most bugs. > Software bugs happen (literally) billions of times per hour You're comparing things with different criticality. A bug that doesn't prevent you from doing your work is like a match that doesn't light up properly. These events happen all the time in the physical world. Bugs that shut down AWS for 24 hours tend to be less frequent... Let's just no enter in a debate about the frequency of "physical world bugs". Yes I admit it was a little knee jerk defensive.
- MisterBastahrd 5y ago
  Yeah, oil spills occur because companies make conscious decisions to do the bare minimum to operate their pipelines. 500K gallons of crude spilled in Louisiana a few weeks back and nobody knew about it until cleanup efforts were underway. Why did the spill occur? It wasn't because the pipeline was engineered poorly. It was because the pipeline was not properly maintained. And people wonder why there are those who do not want an oil sands pipeline carved through an aquifer. Engineers don't work with infinite budgets and they usually are not the people who are making final decisions on either maintenance or implementation. Many of these failures occur because of budget constraints, time constraints, or decision makers who go against the recommendations of experts. IMO, the closest thing to a "software engineer" is a software architect. Everyone else is a craftsman.

skrtskrt 5y ago

> But this is because I was able to apply well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use. I am not sure how this is different from evaluating a library, database technology, or architecture, going through design review, learning properties of distributed systems (which have corresponding proofs by the way) to understand which properties you need to satisfy with a given solution, reading the documentation, viewing other open-source code that uses the technology, reading publications/testimonials from people and companies using it in productions, etc., etc., like we do. In particular "applying simplifying assumptions" - this is what we all have to do particularly in a distributed, cloud-computing world where you are essentially purchasing a conceptual primitive (like "virtual CPU" or "replicated block storage" and building on top of simplifying assumptions about how those work, because you can't walk up to the NAS rack and start hitting it with a hammer to see if the data can be recovered after, the same way you can't hit a steel beam with an actual hurricane to know what will happen. Although if I worked in the datacenter operations team for a cloud provider, I would absolutely hope to one day be able to test how we handle if I yank some plugs or hit the NAS rack with a hammer :)

slingnow 5y ago
It is absolutely wildly different. "Evaluating a library", "reading the documentation", etc., is absolutely NOT the same as basing your calculations on a hundred+ years of rigorously proven methods and deeper physical truths. How could you possibly infer that these are the same thing?
- skrtskrt 5y ago
  software engineering is a younger discipline, we don’t have hundreds of years yet. You seem to think that our understanding of CPU operation or distributed systems isn’t based on physical truth and rigorous testing. Also a programming language or library or whatever has often been deployed by tens of thousands of organizations, across tens if millions of deployments, across trillions of discrete times the code path has been hit, and we know how it acts. That’s rigorous in its own way

yodsanklai 5y ago

> If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering. Totally disagree. Engineer = design and build things. Whether what you build has bugs or not is irrelevant to the definition. > If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering. All science is based on abstraction. Laws of physics used by aerospace engineers are abstractions of some more complex reality.

Scramblejams 5y ago
Is a child performing engineering when they resolve to build a tower of blocks and do so? If not, what distinguishes them from someone who is performing engineering? In your view, are simplification and abstraction the same thing? Or do they differ, and if so, in what way?

karaterobot 5y ago

Love this comment! > (a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0] This might arise from the different contexts without implying a different activity is taking place. Fixing bugs after launch is something you can do in software engineering, but can't really do in (say) structural engineering. If they could invisibly and safely swap out part of a bridge without stopping traffic, I'm betting they'd do it all the time! In software we can, and it makes sense to use this feature of digital products as part of the engineering process, in order to meet other requirements, like time and cost. (Whether it is overused or not is another question. I consider "good engineering" vs. "bad engineering" as distinct from "is engineering" or "is not engineering", ymmv)

varjag 5y ago

From my observations engineers in many disciplines would wing it all the time. Sometimes because of time/budget constraints, or simply because of lack of established methodology for certain corner cases. The scope of 'corner cases' also tended to be a lot larger in their disciplines' infancy: things like bridges (and yes, aircraft) were regularly built with assumptions pulled out of one's asses.

chiyc 5y ago

I appreciate you sharing your perspective! Mine's somewhat different having worked in another industry. I worked in semiconductor manufacturing as a process engineer. What counts as bug in that setting? It's completely expected to have defects in the final wafer. They go through a QA process. Some die can be repaired but others are trash. Die also get graded and low quality chips go to customers with less mission-critical needs. There's also a department dedicated to investigating early failures in defective product from customer returns. Personally, I viewed the product that I delivered as the wafers coming out of the steps I owned. High volume manufacturing is an ongoing process much like software development. As an individual process owner, I had metrics and goals to meet but my processes fit into a larger system I didn't fully understand. Process development happened by incremental changes much like software feature development. We would convert a small percentage of the production line with a new change at one step like you might use feature flags, but we sometimes had to rollback changes when something unexpected came up at yield or test. It might be more the nature of semiconductor manufacturing, but I view failures as part of the engineering process that comes up when we're pushing our tools and systems to new limits.

Scramblejams 5y ago
Good point, (a) doesn't hold up when you're dealing with the bleeding edge. Plenty of experimental airplanes, designed by highly credentialed engineers, fell out of the sky on the way to producing today's safety miracle of commercial aviation. Similar story (hopefully usually less deadly!) with other miracles, like modern semiconductors.
pwr-electronics 5y ago
When I worked in aerospace, there was a big, one-of-a-kind piece of metal where the fabricators had drilled a bunch of rivet holes in the wrong places. The structural engineers had to figure out if they could still use it. There's bugs in everything.
torginus 5y ago
I think a good software analogy for this would having a piece of multi-threaded code that accesses a shared resource using locks. There will probably be some waiting involved (analogous to defects). The engineer determine wha rate of waiting/working is acceptable, and if the software actually does perform like predicted. If it does not, as in the wait(defect) rate is higher, it might indicate a genuine bug in the system (like locks not being released in a timely manner), or a failure of planning.

dataflow 5y ago

How about this one: (c) If your project assumes the underlying device/system will behave exactly as it is told to, then you might be in a discipline that is distinct from engineering. This means "engineering" would include some software projects (like fault-tolerant system design), but exclude many others (like most desktop/mobile/web apps, perhaps with components like databases being exceptions). My rationale for this is that, best as I can tell, traditional engineering is (for the lack of a better phrase) about "taming the real world"—which doesn't always behave the way you tell it to, because it's inherently uncertain, failure-prone, and impossible to model exactly. So if your task is dealing with that, then you're doing engineering. Whereas if your main problem is coming up with the correct specification—but you assume it will be executed faithfully—then it's not really engineering per se, but something else (not sure if we have a name for it). Thoughts?

Scramblejams 5y ago
Intriguing! I'll have to let that percolate...
- dataflow 5y ago
  I haven't fully figured out the implications to be honest. Some are more intuitive than others. For example, it would mean (some?) financial engineering is a misnomer ;) but it would also suggest that designing digital circuits is only engineering in certain cases, like high-speed cases where you have to make the design robust to extraneous analog effects. For what it's worth, I think it somewhat aligns somewhat with your point about abstractions.
  - Scramblejams 5y ago
    I appreciate the focus on abstractions. I'm unenthusiastic about giving up on (b), because when you've got a discipline where anybody can reach for any old terrible abstraction and stand some unholy monstrosity up that actually seems to work okay, I have a difficult time wanting to call it engineering. And I am fully in favor of financial engineering not being engineering. :-)

austincheney 5y ago

> What do I mean by that? My go to example every time is DOM. Out of the software developers I have encountered either online, during employment, or in person maybe 1 out of 50 who actively touch the DOM understand it well enough to have talks about it without wetting the bed. That's pretty tragic because the standard methods in most common use are about 23 years old (DOM Level 2) and take about 2 hours to learn.

908B64B197 5y ago

There's as many definitions of engineering as there are jurisdictions. Someone joked at some point that designing a PCB is real engineering (solidly into EE territory). Chip design as well (designing an ASIC is indeed generally considered to be EE). But replace that ASIC with a microcontroller and firmware and suddenly the firmware writer is no longer an engineer, despite the part having the same spec as the ASIC it replaces. Misplace one of these microcontrollers with the correct firmware on it in the wrong bin and it might even end-up on the same board the ASIC was supposed to go. And nobody would notice a thing. > If we software peeps fully understood our deliverables, we wouldn't have bugs, or at least, we'd always know what bugs are there. In the embedded world that's more true than in "general purpose software" as the problem space is often better defined. There are also Realtime OSs that offer hard guarantees in terms of execution time and memory consumptions (or at least will have a hard cap on the upper bounds). It is possible to develop software that’s extremely predictable and has runtime measured in years. But it’s costly and takes time. > so we clearly have a tolerance for delivering work that we don't fully understand. Yes, when non-critical. You'll see it too with "silent upgrades" of physical products over their lifetime. Some of them are to correct non-critical flaws discovered over time. This tolerance has increased a lot over time as the cost of update has lowered (keep in mind not that long ago OS updates shipped as physical media!). And the cost of shipping bad (non-critical) software isn't the same as shipping defective products (think about the costs of a physical product recall). That allows a level of acceptable risk that’s alien to most other engineering disciplines. From the article: > In Canada you can't even call yourself a Software Engineer unless you're accredited! How much of that is the licensing body trying to squeeze a few dollars here and there? Do they actually enforce those rules? Would it be enforceable (if you can't define it properly, first amendment should apply...).

fphhotchips 5y ago

Isn't aerospace engineering the field that gave us pitot tubes that froze up at high altitude? > well-understood and rigorously accepted simplifying assumptions that were conservative (from the point of view of a factor of safety), and fully encapsulated all the understanding I needed to produce a part fit for use. Isn't even this "reaching for abstractions"? I would argue that software engineering has two factors that result in higher bug counts: the lack of consequence, and the youth of the field. Lack of consequence shows up in errors in other fields, too. How many times has a civil engineer created an intersection that doesn't drain properly, or a curb that was slightly too high? Youth of the field shows up in other engineering fields also. See: pitot tubes, above.

spc476 5y ago

Somehow, the first Tacoma Narrows Bridge comes to mind. Carefully engineered, it still fell apart in a stiff breeze (fortunately, no one was killed).

Ericson2314 5y ago

> (b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1] Yeah my experience is trad engineers don't believe in nice things, haha. That's the difference. Just look at how moribund hardware is with a lack of open source tools compared to software.

torginus 5y ago

I think a key defining trait of engineering is the necessity of having a correct, precise model of the domain you are working in, so that you can solve multifaceted problems with the minimum possible resources. A typical non-engineering characteristic of software is the widespread acceptance of techniques/libraries that claim to make development easier at the cost of increased(outsourced) complexity and efficiency. I think a design technique that (allegedly) allowed you to spend half the time in a CAD software, but the resulting part would be less sturdy and more expensive to make wouldn't be exactly popular. Yet this is the bread and butter of software engineering, and since waste can be arbitrarily big, directly results in Wirth's law, with software consuming the extra resources and regressing to barely acceptable performance. Imo, one of the places when real engineering happens in the software world is video games. Here, there are actual constraints are very tight - one has to simulate a believable world, display 60 frames of meticulously calculated graphics on a clockwork cadence, synchronize players over an unreliable network in real-time, and so on and so forth. And do these things on cheap console hardware whose designers often favored raw performance over ease of use, sometimes to extreme degree, like the PS3. I'm pretty sure I barely scratched the surface. Yet it's commonplace to see chat applications crawl to a halt (Teams) and use enormous resources, while having a fluid UI in a game that just happens to run flawlessly beside a fully rendered 3D game world is considered the price of admission, not some technical feat.

zild3d 5y ago

Also a previous engineer (Systems & radar engineer on DoD projects like missile defense, avionics, etc) and now software engineer. Definitely disagree on both points. > (a) If it's regularly expected that you ship bugs, you might be in a discipline that is distinct from engineering.[0] Every system has bugs. If you aren't expecting, controlling for them, and implementing measures to reduce their impact and likelihood - you might be in a discipline that is distinct from engineering. Why else would redundancy be a critical requirement in just about any mission critical systems? > (b) If you can usually reach for an abstraction to save you, you might be working in something that isn't engineering.[1] Well in radar, missile defense, helicopter systems, it was all abstractions up and down the stack. Maybe the 1000 engineers working on these projects weren't all real engineers? You have to use abstractions if you want to do anything real. You are regularly using models, simulations, tools, integrating with other teams' systems/components which become abstractions.