5 ms·

This is a great comment, and very succinctly put. Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engin

This is a great comment, and very succinctly put. Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics. The 'possible model space' is relatively constrained, and everyone is working under, roughly, the same set of assumptions, rules, and standards. This kind of constraint allows for higher degrees of rigor, because there often is a 'right way' to do things, or an empirical set of tests to verify the quality of an idea. Software is, on the other hand, only slightly more constrained than mathematics in its most basic form. We can introduce artificial constraint by monopolizing a domain with certain ideas that have proven robust and reliable (in the same way that we've decided that, in general, you turn a screw clockwise to tighten it), which in turn allows for the introduction of some engineering-style rigor and standards, but there's nothing really stopping you from stepping back and saying, "well I want to do it this way instead", in the way that an Engineer is prevented, by physics, from saying, "well, I think we should just alter the density of air so that we don't need to worry about lift for these airplanes we're building; they'll just be buoyant!". By and large, you can do that kind of thing in code; you're building the world within which you're going to solve the problem, and you can arrange that world as you see fit (by and large) to make certain aspects of the problem easier (often at the cost of making others harder), in the same way a mathematician does. And if you've got one kind of world you really like, because it works well with how problems decompose in your head, it can, to the parent's point, be really difficult to understand why another representation might be just as useful to someone else's particular brain arrangement. Not trying to make value judgement here, though I do envy and admire engineering rigor. Just a (likely naive) take on a fundamental difference.

jgtrosh 8y ago
When you're fighting for speed on your code, it ends up feeling like what you're describing of that engineering world. Your techniques have to adapt to what is actually happening in the lower layers. When you're fighting for ease of use, you can't make your users forget their preconceptions, you have to adapt to these externalities. I think sometimes engineering and software development have different degrees of freedom, but the difference isn't as clear cut as you make it.
- dmreedy 8y ago
  Agreed, there's definitely a continuum as you go lower down the stack; in the same way that the first programmers were often electrical engineers (with due deference to Ada Lovelace).
  - kens 8y ago
    Are you thinking of any early electrical engineer programmers in particular? The impression I got was that early programmers for scientific applications were largely mathematicians and scientists (e.g. Hopper, Turing, ENIAC programmers, von Neumann), while business programming was more office / business people.
    - dmreedy 8y ago
      Fair; I'm thinking of people like (from disparate periods) Ivan Sutherland, Doug Englebart, Claude Shannon, and so on; folks who came out of EE educations but became computer engineers or computer scientists in practice (and sort of by post-hoc definition)
- yason 8y ago
  I think programming has more trade-offs to choose from, and thus more freedoms. You can make a program slow, fast, small, large, limited, comprehensive, quickly written for a specific case or carefully designed for the generic case, or anything else at the expense of something else. Building a bridge doesn't have much of that: the bridge must withstand loads from the traffic, loads from the elements, material wear across decades; all that without falling down. There are aesthetical components to choose from but generally you can't avoid physics and financial cost when building one. In programming you could choose to go with a number of alternate implementations that are as different as they would be unrealistic if only you were building a bridge instead of software. Anything from tying inflatable boats together to form a walkable chain to act as a bridge to draining all the water out and building a 6+6 lane highway across the bottom of the bay instead. Performance is a likely domain for coming to terms with the limits of the physical qualities of computers but even then there are lots of different flavours of performance to consider, and innumerable ways to trade performance in and something else out.
noobiemcfoob 8y ago
I think engineering disciplines broadly have comparable flexibility to software. Looking to electrical engineering, circuit design is mostly arbitrary once you're within certain physical bounds (such as controlling for noise in a high speed circuit). Regardless of discipline, there seems to be infinity^12 ways to skin their particular cats. Older disciplines just have more "turn clockwise" assumptions built into the mountain that makes their foundation.
klodolph 8y ago
> Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics. As a software engineer who calls what I do "engineering", I have to answer to physics every day. The difference is that the relative cost of everything is skewed so far out of proportion to what other engineers work with that it's hard to account for the differences, and software engineers work with so many orders of magnitude. We are still working with physical stuff, basically refined sand and metal, which consumes electricity and other resources, just like other engineers. Imagine that you were a civil engineer tasked with building a bridge. Except instead of using concrete and steel, I handed you some adamantium at the low, low cost of $0.01 per cubic meter, and a bunch of robots to machine it for you. Designing bridges is easy now, and you can basically make it look like whatever you want, just because adamantium is so amazing. But just because we've made bridge-building trivially easy doesn't mean that civil engineering is obsolete. Adamantium is nice, and all, but now I'm asking you to build a Dyson shell, and you have to tell me that it's not physically possible, even with adamantium. I would love to just handwave the design of the systems I work on, I would love to just arrange pieces however I felt like. Instead I have all these constraints like the reliability of components (hard drives fail), physical laws (speed of light constrains network latency), the memory hierarchy (the software manifestation of constraints on circuits), and all sorts of other problems that I can't just pretend don't exist. I have to choose algorithms that will complete with the computational resources that I have available. Maybe an exact algorithm is not physically realizable, maybe I have to choose some kind of approximation. This is not true in mathematics. In mathematics, algorithms are not necessary (at least, for most mathematicians). In mathematics, I can prove that some object exists without concerning myself with whether some physical system is capable of constructing that object. At the end of the day, I am writing software, and that software is one part of a real, physical system which obeys physical laws. This makes me an engineer. Maybe I play around with 20 orders of magnitude in my designs and the civil engineer plays around in 8, but so what?
- flukus 8y ago
  > At the end of the day, I am writing software, and that software is one part of a real, physical system which obeys physical laws. This makes me an engineer. The person that made my coffee this morning is also an engineer by this definition. Apart from that I agree, we have real constraints to deal with and we can't hand wave away the environment the code runs in.
guelo 8y ago
I think the real difference compared to other engineering is the malleability of our product and the expectation of never-ending modifications. Software is almost never "done". So we have to be concerned about maintainability in a much bigger way than other disciplines.
naasking 8y ago
> Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics So do computer scientists! Random access memory isn't constant time, but logarithmic for physical reasons. Cache effects can dominate big-O for a surprisingly large range of input sizes.
lodi 8y ago
> "...just alter the density of air so that we don't need to worry about lift for these airplanes we're building; they'll just be buoyant!". By and large, you can do that kind of thing in code... A wonderful metaphor. Thanks.

jgtrosh 8y ago

When you're fighting for speed on your code, it ends up feeling like what you're describing of that engineering world. Your techniques have to adapt to what is actually happening in the lower layers. When you're fighting for ease of use, you can't make your users forget their preconceptions, you have to adapt to these externalities. I think sometimes engineering and software development have different degrees of freedom, but the difference isn't as clear cut as you make it.

dmreedy 8y ago
Agreed, there's definitely a continuum as you go lower down the stack; in the same way that the first programmers were often electrical engineers (with due deference to Ada Lovelace).
- kens 8y ago
  Are you thinking of any early electrical engineer programmers in particular? The impression I got was that early programmers for scientific applications were largely mathematicians and scientists (e.g. Hopper, Turing, ENIAC programmers, von Neumann), while business programming was more office / business people.
  - dmreedy 8y ago
    Fair; I'm thinking of people like (from disparate periods) Ivan Sutherland, Doug Englebart, Claude Shannon, and so on; folks who came out of EE educations but became computer engineers or computer scientists in practice (and sort of by post-hoc definition)
yason 8y ago
I think programming has more trade-offs to choose from, and thus more freedoms. You can make a program slow, fast, small, large, limited, comprehensive, quickly written for a specific case or carefully designed for the generic case, or anything else at the expense of something else. Building a bridge doesn't have much of that: the bridge must withstand loads from the traffic, loads from the elements, material wear across decades; all that without falling down. There are aesthetical components to choose from but generally you can't avoid physics and financial cost when building one. In programming you could choose to go with a number of alternate implementations that are as different as they would be unrealistic if only you were building a bridge instead of software. Anything from tying inflatable boats together to form a walkable chain to act as a bridge to draining all the water out and building a 6+6 lane highway across the bottom of the bay instead. Performance is a likely domain for coming to terms with the limits of the physical qualities of computers but even then there are lots of different flavours of performance to consider, and innumerable ways to trade performance in and something else out.

noobiemcfoob 8y ago

I think engineering disciplines broadly have comparable flexibility to software. Looking to electrical engineering, circuit design is mostly arbitrary once you're within certain physical bounds (such as controlling for noise in a high speed circuit). Regardless of discipline, there seems to be infinity^12 ways to skin their particular cats. Older disciplines just have more "turn clockwise" assumptions built into the mountain that makes their foundation.

klodolph 8y ago

> Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics. As a software engineer who calls what I do "engineering", I have to answer to physics every day. The difference is that the relative cost of everything is skewed so far out of proportion to what other engineers work with that it's hard to account for the differences, and software engineers work with so many orders of magnitude. We are still working with physical stuff, basically refined sand and metal, which consumes electricity and other resources, just like other engineers. Imagine that you were a civil engineer tasked with building a bridge. Except instead of using concrete and steel, I handed you some adamantium at the low, low cost of $0.01 per cubic meter, and a bunch of robots to machine it for you. Designing bridges is easy now, and you can basically make it look like whatever you want, just because adamantium is so amazing. But just because we've made bridge-building trivially easy doesn't mean that civil engineering is obsolete. Adamantium is nice, and all, but now I'm asking you to build a Dyson shell, and you have to tell me that it's not physically possible, even with adamantium. I would love to just handwave the design of the systems I work on, I would love to just arrange pieces however I felt like. Instead I have all these constraints like the reliability of components (hard drives fail), physical laws (speed of light constrains network latency), the memory hierarchy (the software manifestation of constraints on circuits), and all sorts of other problems that I can't just pretend don't exist. I have to choose algorithms that will complete with the computational resources that I have available. Maybe an exact algorithm is not physically realizable, maybe I have to choose some kind of approximation. This is not true in mathematics. In mathematics, algorithms are not necessary (at least, for most mathematicians). In mathematics, I can prove that some object exists without concerning myself with whether some physical system is capable of constructing that object. At the end of the day, I am writing software, and that software is one part of a real, physical system which obeys physical laws. This makes me an engineer. Maybe I play around with 20 orders of magnitude in my designs and the civil engineer plays around in 8, but so what?

flukus 8y ago
> At the end of the day, I am writing software, and that software is one part of a real, physical system which obeys physical laws. This makes me an engineer. The person that made my coffee this morning is also an engineer by this definition. Apart from that I agree, we have real constraints to deal with and we can't hand wave away the environment the code runs in.

guelo 8y ago

I think the real difference compared to other engineering is the malleability of our product and the expectation of never-ending modifications. Software is almost never "done". So we have to be concerned about maintainability in a much bigger way than other disciplines.

naasking 8y ago

> Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics So do computer scientists! Random access memory isn't constant time, but logarithmic for physical reasons. Cache effects can dominate big-O for a surprisingly large range of input sizes.

lodi 8y ago

> "...just alter the density of air so that we don't need to worry about lift for these airplanes we're building; they'll just be buoyant!". By and large, you can do that kind of thing in code... A wonderful metaphor. Thanks.