8 ms·

Software Is Easy, Hardware Is Of Medium Difficulty

33 points by pwnna 13y ago

angersock 13y ago
This was the root of my frustration with my time studying mechanical engineering. Every course I took in the CS, applied math, or EE departments required us to, you know, actually do something. In my POSIX programming class, we wrote lots of programs (malloc, web proxies, and so on). In my graphics class, we wrote renderers (while paper tests covered the algebra of geometry). In my PDE classes, we wrote simulation code in Matlab and saw it run on wave and heat equations. In mech, though, scarcely any classes had an experimental component. Fluids? Nope. Heat transfer? Negative, barring a baking orb lab and a Reynold's number lab. Machine design? Hah, fat chance--a 25 page report on a fucking bolt was the capstone assignment (alternately, a failure analysis on a gear tooth that chipped in a transmission). Control systems? A few tedious labs more suited to padding out a grad student's paper on teaching engineering than actually, you know, teaching us anything. The height of this nonsense was a mandatory lab on power generation--one in which we finally got to run a steam powerplant! Except we didn't, and were given the results to run our analysis on instead. Sitting in the campus pub afterwards and grousing into my beer, a facilities guy from the central plant expressed surprise--they'd specifically made sure to have steam run out to make that lab happen. The lab was cancelled because that steam wasn't available, nominally--more likely, the student running it was looking for a way out. The only good labs we had were an industrial processes lab (machining, welding, and so on), and a strength of materials lab (tension, torsion, and whatnot). I guarantee that at the end of four years any of our CS or EE kids were substantially better coders--I cannot claim the same for the mechanical engineers I graduated with. Our final design project was our one true chance to show that we could actually build something, and for many teams that too resulted in failure. EDIT: The problem with so much of this is that there are perfectly good ways these things could be taught. Machine design could have you, you know, actually manufacture some cams or build gearboxes. Heat transfer could have you build heat sinks, manage fluid flows, or create exchangers. Control systems could have you build robots or invert pendulums or do any other damn fool cool thing that requires signal transforms. It's just such a goddamn disappoint.
- pwnna 13y ago
  OP here. While I agree with what you say, I just don't know how this can be changed. It takes substantially more resources to do anything in mech. Sometimes you can't even lift the stuff you're working with without some other expensive machinery.
  - angersock 13y ago
    Quite so. That said, if our tuition is north of a hundred grand (as mine was), one wonders that that expense cannot be borne by the institution. Even building simple structures and predicting their failure would be a worthwhile endeavor.
    - pwnna 13y ago
      Now that I think about it... do we ever predict failures in software? Things just seem to break.. and we go in and fix it after. At least that is my impression.
  - greendata 13y ago
    Chemical engineer who now mostly works as a programmer checking in. This is 100% true.
  - beambot 13y ago
    Coops, internships, design courses (like MIT 2.007), fabrication courses (How to build almost anything), undergrad research coursework, hacking w/ friends. It sounds like many of these schools do a poor job... which means it's even more important for motivated students to seek out opportunities outside the classroom. College is (largely) what you make of it, not what the default curriculum spoon feeds you.
    - pwnna 13y ago
      I think you're oversimplifying the problem. When I do programming stuff, a large fraction of the time is spent debugging because my program crashed. I cannot afford my hardware project "crashing" as that may permanently damage a part and thereby pushing back when i can complete the project by a long time (gotta wait for manufacturing). Sometimes I simply don't have the extra money to buy the replacement.. and this is assuming I have the cash to make the first part after I designed it.. Edit: Now I know if you're motivated enough you could do this, but when all of these factors combine (time delay in getting parts, destroyed parts, lack of funds), you lose momentum fairly quickly. The alternative is that you could be right the first time by doing calculations, simulations, what have you. But that means you need a deep understanding of a lot of things to begin with, which is what you're trying to gain.
jklp 13y ago
This reminds me of an article I read about a competition, to see who the first person was to build a human-powered plane. http://www.fastcodesign.com/1663488/wanna-solve-impossible-problems-find-ways-to-fail-quicker http://www.fastcodesign.com/1663488/wanna-solve-impossible-p... Similar to what the OP is saying, the engineer realized that human powered flight wasn't the problem he was solving, but the process of failing fast and iterating.
georgemcbay 13y ago
Why even look for a distinction between software and hardware when it comes to "difficulty"? Regardless of whether a system is software or hardware: simple systems are easy, complex systems are hard. The more complexity, points of interaction and levels of abstraction you add to either type of system the more difficult it becomes for any single person to keep track of it all. Writing a JavaScript form validator is easy, writing a full featured bare-metal OS is hard. Designing a simple LED light circuit is easy, designing a modern CPU is hard.
- deleted 13y ago
  [deleted]
- jjoonathan 13y ago
  > simple systems are easy, complex systems are hard This is exactly the oversimplification these posts intended to disprove. The complexity of an airplane or rocket, measured in terms of design components or interacting subsystems or what have you, is miniscule compared to any piece of software that could be written with the same budget. An even more extreme example would be science: after 6 years, the complexity of a PhD's discoveries is microscopic next to the complexity of software that he/she could have written (or did write) in the same time. The amount of functional complexity achievable per effort invested varies dramatically between fields based on the time and cost of iteration, the time, cost, and power of relevant diagnostic tools, and the availability of domain-specific knowledge. It's an important fact to keep in mind when judging someone else's work or deciding to switch occupations/markets/fields.
  - pwnna 13y ago
    > The complexity of an airplane or rocket, measured in terms of design components or interacting subsystems or what have you, is miniscule compared to any piece of software that could be written with the same budget While I suspect that this is probably true. I still would like to pose the question... Are they? Or is it simply because we don't know it, it then seem easy?
    - 13y ago
joe_the_user 13y ago
What's harder? Racing a bicycle up a mountain or racing it on level ground? Of course they're both as hard as you want them to be and are very hard at top levels. This kind of comparison might seem just as ridiculous. The one thing about programming (whether pure software or related also to hardware) is that programming is something like the easiest seeming hard activity known to humanity. There's something like a natural illusion in the human mind which makes people believe that changing XYZ in a program is easy, just because it is easy to imagine what it would be like to have the change or just because the program itself is just "brain stuff". Even the programmer himself/herself, after a couple days rest will feel the pull, the plausibility of the argument that change Y should be easy even when the torture of making change X is still weighing on him/her.
alexvr 13y ago
I wanted to be an aerospace engineer until the day I discovered programming.
- pwnna 13y ago
  I always wanted to make rockets. Learning of programming does not change that for me :) The lack of funding however... :\
com2kid 13y ago
Hardware is easy because it is bounded by physical constraints of reality, whereas software has unlimited complexity bounded only by the number of hours of coding put in. Hardware is hard because one must work within the constraints of reality, software is easy because almost anything imaginable is possible. Both are fair viewpoints.
- pwnna 13y ago
  I think this is the best summary I've heard over software vs traditional engineering to date.
- alok-g 13y ago
  Just that I am not sure if either one is correct. Hardware design (in HDLs for example) is very much like software development. There may be a very large number of lines of code (resulting in a very large number of transistors on the chip). Just like a language like C++ that can have many intricacies, the hardware can have many issues that are sometimes hard to nail down during design and simulation. When thinking that anything imaginable is possible in software while comparing it to hardware, you must keep in mind that the software is ultimately running on the hardware. Anything imaginable is possible still.
  - pwnna 13y ago
    The hardware here is more referring to tangible, physical things rather than computer hardware.
cmac2992 13y ago
read something similar a few weeks ago. http://andrewlinfoot.com/why-every-1st-time-entrepreneur-should-start-a-software-company/ http://andrewlinfoot.com/why-every-1st-time-entrepreneur-sho... Its a completely different way to think about things when you can push an update versus doing an expensive manufacturing run.
gcb0 13y ago
it fails to understand the root issue mentioned on the article it is responding to. The original article says: everyone settled down for a crapy simulation software and implementations are terrible. so, the conclusion of this piece "there is no way to realistic improve" is way off. Maybe he should get at least a couple years under the belt before trying becoming a pundit.
rrrrrraul 13y ago
Hi all, mechanical & aerospace engineer here. Like the author alluded to, I DON'T think software is easy and hardware is 'medium' difficulty. Just my .02, hardware is expensive in terms of design, develop, test & iterate when compared to software development at the university level. From my experience, if you're studying mechanical/aero/civil/mechatronics/or similar fields, get involved in a student project / organization (as some one else has already commented) that culminates in the manufacturing of some doodad (plane, car, bridge, canoe, rocket, etc). Not only does it look good and sound good when interviewing for internships, it's actually really good experience to have if you decide to go and work at a large engineering firm after your studies (where they don't let the new young guy design the new rocket engine, for example); and having that bit of experience from designing your gizmo and then seeing it explode/rupture/sink when put in to practice is a valuable lesson learned to recall when you're designing a part for a large corporation. And as far as the universities I have attended, it is true and unfortunate that a lot of universities MAINLY focus on analytical work (undeniably necessary, but not sufficient). -currently working in the aerospace industry
siralonso 13y ago
I used to be an aerospace engineer as well, so I couldn't resist writing up some thoughts: https://medium.com/geek-empire-1/b6be6db5f3c3 https://medium.com/geek-empire-1/b6be6db5f3c3
- pwnna 13y ago
  This is awesome. Putting some perspective into this conversation with experience! Definitely learned plenty.
- rrrrrraul 13y ago
  Another good data point. It is indeed different.
peterwwillis 13y ago
Has anyone here ever debugged a program you couldn't run? It's liberating. You spend hours using your brain, combing lines of code, tracing execution, taking notes. It's similar to writing an algorithm in a job interview; will this code really work? What kind of problems might occur? Hmm, better fix this part and check again. Rarely, but sometimes, i'll encounter a problem and troubleshoot it, and each time I find a bug and fix it, it turns out it was completely unrelated to my problem. Looking hard at the code just makes potential bugs pop up that I hadn't seen before. It's cases like these that made me realize the iterative software development model of write, test, debug, repeat, was a huge waste of time. If I actually review all my code I catch bugs quicker.

33 points by pwnna 13y ago

This was the root of my frustration with my time studying mechanical engineering. Every course I took in the CS, applied math, or EE departments required us to, you know, actually do something. In my POSIX programming class, we wrote lots of programs (malloc, web proxies, and so on). In my graphics class, we wrote renderers (while paper tests covered the algebra of geometry). In my PDE classes, we wrote simulation code in Matlab and saw it run on wave and heat equations. In mech, though, scarcely any classes had an experimental component. Fluids? Nope. Heat transfer? Negative, barring a baking orb lab and a Reynold's number lab. Machine design? Hah, fat chance--a 25 page report on a fucking bolt was the capstone assignment (alternately, a failure analysis on a gear tooth that chipped in a transmission). Control systems? A few tedious labs more suited to padding out a grad student's paper on teaching engineering than actually, you know, teaching us anything. The height of this nonsense was a mandatory lab on power generation--one in which we finally got to run a steam powerplant! Except we didn't, and were given the results to run our analysis on instead. Sitting in the campus pub afterwards and grousing into my beer, a facilities guy from the central plant expressed surprise--they'd specifically made sure to have steam run out to make that lab happen. The lab was cancelled because that steam wasn't available, nominally--more likely, the student running it was looking for a way out. The only good labs we had were an industrial processes lab (machining, welding, and so on), and a strength of materials lab (tension, torsion, and whatnot). I guarantee that at the end of four years any of our CS or EE kids were substantially better coders--I cannot claim the same for the mechanical engineers I graduated with. Our final design project was our one true chance to show that we could actually build something, and for many teams that too resulted in failure. EDIT: The problem with so much of this is that there are perfectly good ways these things could be taught. Machine design could have you, you know, actually manufacture some cams or build gearboxes. Heat transfer could have you build heat sinks, manage fluid flows, or create exchangers. Control systems could have you build robots or invert pendulums or do any other damn fool cool thing that requires signal transforms. It's just such a goddamn disappoint.

pwnna 13y ago
OP here. While I agree with what you say, I just don't know how this can be changed. It takes substantially more resources to do anything in mech. Sometimes you can't even lift the stuff you're working with without some other expensive machinery.
- angersock 13y ago
  Quite so. That said, if our tuition is north of a hundred grand (as mine was), one wonders that that expense cannot be borne by the institution. Even building simple structures and predicting their failure would be a worthwhile endeavor.
  - pwnna 13y ago
    Now that I think about it... do we ever predict failures in software? Things just seem to break.. and we go in and fix it after. At least that is my impression.
- greendata 13y ago
  Chemical engineer who now mostly works as a programmer checking in. This is 100% true.
- beambot 13y ago
  Coops, internships, design courses (like MIT 2.007), fabrication courses (How to build almost anything), undergrad research coursework, hacking w/ friends. It sounds like many of these schools do a poor job... which means it's even more important for motivated students to seek out opportunities outside the classroom. College is (largely) what you make of it, not what the default curriculum spoon feeds you.
  - pwnna 13y ago
    I think you're oversimplifying the problem. When I do programming stuff, a large fraction of the time is spent debugging because my program crashed. I cannot afford my hardware project "crashing" as that may permanently damage a part and thereby pushing back when i can complete the project by a long time (gotta wait for manufacturing). Sometimes I simply don't have the extra money to buy the replacement.. and this is assuming I have the cash to make the first part after I designed it.. Edit: Now I know if you're motivated enough you could do this, but when all of these factors combine (time delay in getting parts, destroyed parts, lack of funds), you lose momentum fairly quickly. The alternative is that you could be right the first time by doing calculations, simulations, what have you. But that means you need a deep understanding of a lot of things to begin with, which is what you're trying to gain.

jklp 13y ago

This reminds me of an article I read about a competition, to see who the first person was to build a human-powered plane. http://www.fastcodesign.com/1663488/wanna-solve-impossible-problems-find-ways-to-fail-quicker http://www.fastcodesign.com/1663488/wanna-solve-impossible-p... Similar to what the OP is saying, the engineer realized that human powered flight wasn't the problem he was solving, but the process of failing fast and iterating.

georgemcbay 13y ago

Why even look for a distinction between software and hardware when it comes to "difficulty"? Regardless of whether a system is software or hardware: simple systems are easy, complex systems are hard. The more complexity, points of interaction and levels of abstraction you add to either type of system the more difficult it becomes for any single person to keep track of it all. Writing a JavaScript form validator is easy, writing a full featured bare-metal OS is hard. Designing a simple LED light circuit is easy, designing a modern CPU is hard.

deleted 13y ago
[deleted]
jjoonathan 13y ago
> simple systems are easy, complex systems are hard This is exactly the oversimplification these posts intended to disprove. The complexity of an airplane or rocket, measured in terms of design components or interacting subsystems or what have you, is miniscule compared to any piece of software that could be written with the same budget. An even more extreme example would be science: after 6 years, the complexity of a PhD's discoveries is microscopic next to the complexity of software that he/she could have written (or did write) in the same time. The amount of functional complexity achievable per effort invested varies dramatically between fields based on the time and cost of iteration, the time, cost, and power of relevant diagnostic tools, and the availability of domain-specific knowledge. It's an important fact to keep in mind when judging someone else's work or deciding to switch occupations/markets/fields.
- pwnna 13y ago
  > The complexity of an airplane or rocket, measured in terms of design components or interacting subsystems or what have you, is miniscule compared to any piece of software that could be written with the same budget While I suspect that this is probably true. I still would like to pose the question... Are they? Or is it simply because we don't know it, it then seem easy?
  - 13y ago

joe_the_user 13y ago

What's harder? Racing a bicycle up a mountain or racing it on level ground? Of course they're both as hard as you want them to be and are very hard at top levels. This kind of comparison might seem just as ridiculous. The one thing about programming (whether pure software or related also to hardware) is that programming is something like the easiest seeming hard activity known to humanity. There's something like a natural illusion in the human mind which makes people believe that changing XYZ in a program is easy, just because it is easy to imagine what it would be like to have the change or just because the program itself is just "brain stuff". Even the programmer himself/herself, after a couple days rest will feel the pull, the plausibility of the argument that change Y should be easy even when the torture of making change X is still weighing on him/her.

alexvr 13y ago

I wanted to be an aerospace engineer until the day I discovered programming.

pwnna 13y ago
I always wanted to make rockets. Learning of programming does not change that for me :) The lack of funding however... :\

com2kid 13y ago

Hardware is easy because it is bounded by physical constraints of reality, whereas software has unlimited complexity bounded only by the number of hours of coding put in. Hardware is hard because one must work within the constraints of reality, software is easy because almost anything imaginable is possible. Both are fair viewpoints.

pwnna 13y ago
I think this is the best summary I've heard over software vs traditional engineering to date.
alok-g 13y ago
Just that I am not sure if either one is correct. Hardware design (in HDLs for example) is very much like software development. There may be a very large number of lines of code (resulting in a very large number of transistors on the chip). Just like a language like C++ that can have many intricacies, the hardware can have many issues that are sometimes hard to nail down during design and simulation. When thinking that anything imaginable is possible in software while comparing it to hardware, you must keep in mind that the software is ultimately running on the hardware. Anything imaginable is possible still.
- pwnna 13y ago
  The hardware here is more referring to tangible, physical things rather than computer hardware.

cmac2992 13y ago

read something similar a few weeks ago. http://andrewlinfoot.com/why-every-1st-time-entrepreneur-should-start-a-software-company/ http://andrewlinfoot.com/why-every-1st-time-entrepreneur-sho... Its a completely different way to think about things when you can push an update versus doing an expensive manufacturing run.

gcb0 13y ago

it fails to understand the root issue mentioned on the article it is responding to. The original article says: everyone settled down for a crapy simulation software and implementations are terrible. so, the conclusion of this piece "there is no way to realistic improve" is way off. Maybe he should get at least a couple years under the belt before trying becoming a pundit.

rrrrrraul 13y ago

Hi all, mechanical & aerospace engineer here. Like the author alluded to, I DON'T think software is easy and hardware is 'medium' difficulty. Just my .02, hardware is expensive in terms of design, develop, test & iterate when compared to software development at the university level. From my experience, if you're studying mechanical/aero/civil/mechatronics/or similar fields, get involved in a student project / organization (as some one else has already commented) that culminates in the manufacturing of some doodad (plane, car, bridge, canoe, rocket, etc). Not only does it look good and sound good when interviewing for internships, it's actually really good experience to have if you decide to go and work at a large engineering firm after your studies (where they don't let the new young guy design the new rocket engine, for example); and having that bit of experience from designing your gizmo and then seeing it explode/rupture/sink when put in to practice is a valuable lesson learned to recall when you're designing a part for a large corporation. And as far as the universities I have attended, it is true and unfortunate that a lot of universities MAINLY focus on analytical work (undeniably necessary, but not sufficient). -currently working in the aerospace industry

siralonso 13y ago

I used to be an aerospace engineer as well, so I couldn't resist writing up some thoughts: https://medium.com/geek-empire-1/b6be6db5f3c3 https://medium.com/geek-empire-1/b6be6db5f3c3

pwnna 13y ago
This is awesome. Putting some perspective into this conversation with experience! Definitely learned plenty.
rrrrrraul 13y ago
Another good data point. It is indeed different.

peterwwillis 13y ago

Has anyone here ever debugged a program you couldn't run? It's liberating. You spend hours using your brain, combing lines of code, tracing execution, taking notes. It's similar to writing an algorithm in a job interview; will this code really work? What kind of problems might occur? Hmm, better fix this part and check again. Rarely, but sometimes, i'll encounter a problem and troubleshoot it, and each time I find a bug and fix it, it turns out it was completely unrelated to my problem. Looking hard at the code just makes potential bugs pop up that I hadn't seen before. It's cases like these that made me realize the iterative software development model of write, test, debug, repeat, was a huge waste of time. If I actually review all my code I catch bugs quicker.