Software Is Easy, Hardware Is Of Medium Difficulty | Hacker News Reader

Software Is Easy, Hardware Is Of Medium Difficulty

shuhaowu.com

33 pointspwnna44 comments

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.

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.

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.

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.

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.

Chemical engineer who now mostly works as a programmer checking in. This is 100% true.

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.

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.

I'm talking about how to get real hands-on experience during college... not with the difficulties of hardware. The grandparent mentioned how his curriculum offered poor training -- not all schools are so inept.

Incidentally... I'm a hardware engineer. I built large mobile manipulating robots during gradschool, and I routinely build electronics projects at home. I'm well aware of "hardware problems" (and software bugs that cause real physical damage).

To address your comment: learning how to do the fabrication and hardware debugging yourself is a key part of engineering physical goods. Digital fabrication is nice, but it's not the end-all be-all. For robot fabrication, you can't beat cardboard prototyping, 3D printers, laser cutters, drill press, and table saws. For circuit boards, I routinely use a hot-air rework, exacto knifes (to cut traces), and header breakouts for debugging. Nothing ever works the first time. That's why you learn how to design in a way that facilitates debugging. (All of this is so much more approachable with neighborhood hackerspaces / TechShops.)

EDIT: I have no idea how students of "big" engineering go about getting hands-on experience. Building a bridge is a bit different from robotics and electronics. I presume it has many sub-specialties. I suppose this makes coops and internships even more important.

Yeah, incidentally I also have no idea how people in my field are suppose to get hands on experience at home.

Aerospace engineer here (now doing software stuff). Around the time I left my alma mater was doing a good job shifting to more courses that involved actually building hardware. Their term for it was DBT for "design, build, test."

It's expensive though. A lot of times students have to go fundraise to pay for their projects. My annual donation to the university is now earmarked specifically for supplies for a couple of undergrad DBT courses.

I'd encourage you to get back in touch with your old department and give them your above feedback, I'm sure they'd love to hear from you.

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

This is why student engineering team projects exist. Solar Car, Formula SAE, Human-Powered Helicopter etc. Also, most mechanical engineering jobs are in fact not hands-on, are not "design this radically new machine" (more like "tweak this design so it meets slightly different requirements"), and certainly not turning a lathe (that's for technicians/machinists). Putting more design experience into an ME curriculum means taking out some of the analysis/theory (it takes a long time to build stuff, that's why engineering and manufacturing are separate departments), which is a disservice to the students heading toward pure research and academia.

I once heard a friend of mine who complain that engineers are too disconnected from their work. They would design the thing but never once go and actually checkout the physical products that they designed.

I wonder if including things like "turning a lathe" would benefit engineering students. They could in theory design a part to accomplish a certain task (maybe design a fan blade that's unconventional) and analyze it, compare with how it is traditionally done, and so forth.

Either way, one of the best feelings in engineering for me is go draw a 3D rendering for a class and watch it show up as something I can hold in my hand 2 weeks later. No amount of deploying/pushing/launching in software can ever beat that, yet.

"Either way, one of the best feelings in engineering for me is go draw a 3D rendering for a class and watch it show up as something I can hold in my hand 2 weeks later. No amount of deploying/pushing/launching in software can ever beat that, yet."

Embedded development offers this gratification.

I'm currently trying to shift my out-of-hours efforts over to more hardware work (Raspberry Pi, Arduino, now Udoo and Cubieboard).

I feel like I'm missing a huge amount of electronics knowledge as soon as I see a discussion about how such and such a trace has been misplaced on a revision of a board or how certain pins could have been better used as an extra SD card reader (ref: the Udoo board)

Is there a less time-intensive way to pick up an understanding of hardware (I'm currently a software guy) than to go an do an ME or EE? I'm certainly not looking for an easy way out but at the moment it feels like trying to go from crawling to supersonic flight.

Have you looked at nand2tetris? http://www.nand2tetris.org/

Going even farther back up the chain there's stuff like this: http://www.jpmsupply.com/servlet/the-1082/AM,-Radio,-Solder/...

NAND2Tetris looks fantastic, thank you!

Actually, building and playing with published Raspberry Pi or Arduino projects wouldn't be too bad a way to go. Most of the designs are open, and hobbyists tend not to overcomplicate things. See how many layers of the onion you can peel back, or what small changes you can make.

Choose a board and see how much mileage you can get out of it.

For the lowest level nuts and bolts, Horowitz and Hill's _Art of Electronics_ is still a classic. Going through the first few chapter exercises will get you thinking in terms of voltages and currents.

Heh, I seem to lose motivation after the first set of blinkenlights, or (this week) when I burnt out my one buzzer by misreading which resistor it needed.

I think I'll go back to a breadboard for a while - Art of Electronics looks like what I need right now.

Edit: Egads! $150AUD for that book

Try for an older edition, second hand. The fundamentals haven't changed.

In fact, that brings up an idea for a way that hardware is sometimes easier than software. The laws of physics that constrain our designs don't go obsolete every 2 weeks.

Would 3D printing help with some projects?

Absolutely. Best experience of being in engineering thus far.

However that is still quite limited given what we learn.

You're sure you're not talking about MechEng undergrad program at my school? (sarcasm)

That's stark reality. Nowadays they have too much spherical cow in MechEng curriculum. But that said, you're free to spend your time on internship...

The main problem with getting the type of experience you are suggesting in mechanical engineering is that it would be very expensive to do, and there is just too broad of a range of topics to cover practically.

My school definitely focused on practical skill more than yours, with 4 design projects (one was a paper only project) over the course of our degree. We also had a course that was just mechanical engineering labs which covered topics like fluids and heat transfer. Even in courses like Machine Design, the focus was somewhat on design, with all the assignments being miniature design projects where you had to specify real components and justify your choices to the instructor and class. Still students graduated with essentially no practical engineering skills.

You have to take it upon yourself to get the practical experience in your area of interest, be it through co-op jobs and/or student teams. If you don't, the job market is not interested in you.

I think there is going to be some changes coming to traditional engineering education relatively soon. My local professional association seems to be pushing to make the schooling more practical, though nothing major has come of it, just a couple of smaller course changes.

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.

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

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

It's not easy. It's damned difficult and we both know it. But effort "funnels down" into conceptually simple results even more often in non-software engineering. It has to, or physical engineers would never get anything done. Choices like fuel/oxidizer composition, stage design, and nozzle type can be (relatively) easily specified no matter how much trouble went into deciding between alternatives. Pages of physics calculations and days of simulation bake down into a few numerical parameters in the final design.

I think what's happening here is that you know and respect the amount of effort that goes into rocketry and your mind is inferring a level of complexity that matches. Effort(times)skill is one correct way to judge the magnitude of a project, but I argue that complexity of the product bears little relation to either effort(times)skill or the project's success.

Rocketry was a bad example because the scale of a typical rocketry project is so large that dividing by cost (or effort(times)skill) becomes critical to making the comparison.

As someone who is an actual systems engineer, and competent in fields including both programming and physical, the point isn't difficulty but iteration cost. It costs next to nothing to push a modification to software. Worst case, it fails, and as long as you are careful with testing things will probably be fine.

Anything in the real world both incurs significant logistical cost as well as many points of unpredictable failure. I've seen thermocouples rated to 1100C catch fire when they hit 600C. Designing a new part for a new idea for a mechanical subsystem can take weeks to make, cost $1000+ easily, and might not work due to very easy to make errors.

So maybe the way to say it is that the abstraction barriers put around non-software parts of a system make them appear less complex, but what we're really saying is that the complexity inside of the box that we're dealing with is smaller.

As someone who learned CS before diving into MechEng, I must conclude that this is nothing but truth. The problem is, once physics gets into the equation, everything goes so complex that you can't live without approximations. But apparently in MechEng you can't live with spherical cows in vacuum, either, so you need models that could represent what you really care about (strength, rigidity, dynamic stability, structural integrity, wear resistance... just to name a few) and there you go -- complex, even when you only have a few "components".

TL;DR : Sure. MechEng seems easy.

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.

I think this is the best summary I've heard over software vs traditional engineering to date.

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.

The hardware here is more referring to tangible, physical things rather than computer hardware.

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

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

This is awesome. Putting some perspective into this conversation with experience! Definitely learned plenty.

Another good data point. It is indeed different.

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.

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

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.

read something similar a few weeks ago.

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.

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

I always wanted to make rockets. Learning of programming does not change that for me :)

The lack of funding however... :\

Reply on news.ycombinator.com