
Software Is Easy, Hardware Is Of Medium Difficulty - pwnna
https://shuhaowu.com/blog/software_is_easy.html
======
joe_the_user
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.

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

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

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

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

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

~~~
alok-g
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
The hardware here is more referring to tangible, physical things rather than
computer hardware.

------
rrrrrraul
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
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
This is awesome. Putting some perspective into this conversation with
experience! Definitely learned plenty.

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

------
jklp
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...](http://www.fastcodesign.com/1663488/wanna-solve-impossible-
problems-find-ways-to-fail-quicker)

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.

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

------
cmac2992
read something similar a few weeks ago.

[http://andrewlinfoot.com/why-every-1st-time-entrepreneur-
sho...](http://andrewlinfoot.com/why-every-1st-time-entrepreneur-should-start-
a-software-company/)

Its a completely different way to think about things when you can push an
update versus doing an expensive manufacturing run.

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

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

The lack of funding however... :\

