5 ms·

Is software easier or harder than hardware? Somehow people seem to assume software is easier, but then there are at least as many critical failures blamed on s

by dzdt 10y ago

Is software easier or harder than hardware? Somehow people seem to assume software is easier, but then there are at least as many critical failures blamed on software as on hardware. Maybe there are different curves: software is easy to get to 90% working but hard to get from there to 99.9%. Hardware is hard to get to 90% working but easy to get from there to 99.9%.

nickpeterson 10y ago
I don't know much in the way of electrical engineering, but I think the complexity possible is fairly close, but its likely easier to judge a hardware design as being sound since it ultimately has to tie back to reality. I think the complexity of software is that it's almost completely abstraction. So the question reminds me of someone asking, "What's harder, physics or philosophy?"
SixSigma 10y ago
> the lander's computer thought it was ... > led the craft to believe it was... Don't anthropomorphize computers, they hate that. As an armchair space explorer, I would have imagined such a crucial part of the mission had serious redundancy.
- onion2k 10y ago
  I would have imagined such a crucial part of the mission had serious redundancy Redundancy adds either weight if you're computing things on two systems at once, or time if you're recomputing using different code. I'd guess that working out the balance between risk of failure, weight and time is a very complicated problem.
  - pixl97 10y ago
    Also redundancy doesn't solve a lot of potential problems. What if your redundant systems disagree? Which one is wrong?
- madaxe_again 10y ago
  It probably did, and whatever went wrong went wrong across the redundant systems, which is why they're thinking it's a bug. It could be something straightforward that presented an unexpected input and made it behave in an equally unexpected fashion. I'd imagine they're currently replaying the sensor data to an instance on earth and seeing how it responds.
- dzdt 10y ago
  I think the anthropomorphizing in this case is fine. Someone familiar with programming easily takes "computer thought it was on the ground" as shorthand for "computer began executing subroutines designed to activate when the craft was on the ground." The anthropomorphized version is more concise for someone familiar with and more understandable for someone unfamiliar with the inner details of computer systems.
  - andars 10y ago
    I think it was a joke, seeing as SixSigma proceeded to anthropomorphize computers ("they hate that").
    - SixSigma 10y ago
      A bit of both. I actually don't think anthropomorphization is helpful in discussions with the lay public but I'm not that serious about it.
maggit 10y ago
Perhaps it is also a matter of how you fix it. Generally software bugs can be fixed by patching over the Internet, making them less scary, whereas hardware bugs are set in stone. (Stone is mostly silicon, right?) Of course, this is a bit different for software we ship to other planets :P
- logfromblammo 10y ago
  By mass, stone is mostly oxygen. Silicon is in second place.
user5994461 10y ago
From my experience working across both industries: Software is harder than hardware (generally speaking). The root cause is that hardware has clear purpose and is limited by the real world. An aircraft from 2015 or from 2000 does the same thing: Get you from Point A to Point B, same world, same constraints, same goal. A software that does something today. It doesn't give any clue about what it will be or do in 2-5-10 years. IMO: Software projects are way more ambitious, more complex and evolving faster than hardware. What is expected from software is NOT expected (nor achievable) in hardware at all, that's one of the first thing I noticed. --- Nonetheless, hardware can run software onboard. So you get hardware and software dev projects, both running along. That get some quirks of both world. IMO, the hardware [and real world] limitations will quickly limit the software.
tremon 10y ago
Is software easier or harder than hardware? That's hard to say in general. With current practices, I'd say software is harder to get right, but that is mainly due to a failure to spec correctly. Hardware is engineered with very tight controls: dimensions, shapes, and properties are all produced according to a specification that doesn't just specify its nominal values, but also the acceptable tolerance for any deviations. No software that I know of is engineered to the same level of precision as hardware. The lack of specification-guided tooling (and validation for 3rd-party components) is what puts software development not even in the same league as hardware development.
- scrollaway 10y ago
  > No software that I know of is engineered to the same level of precision as hardware. Are you counting NASA-produced software? I'm not familiar with ESA's software pipeline but I imagine it's similar.
  - tremon 10y ago
    Sadly, I'm not. I truly wish I could say that NASA-produced software is within the range of "software that I know of", but it's not.
- jack1243star 10y ago
  Computing Needs Time [1], which focuses on the handling of time, is a nice read on this topic from the software point of view. [1] http://digitalassets.lib.berkeley.edu/techreports/ucb/text/EECS-2009-30.pdf http://digitalassets.lib.berkeley.edu/techreports/ucb/text/E...
henrik_w 10y ago
On that subject, I like this quote: "Hardware eventually fails. Software eventually works." -- Michael Hartung
tezza 10y ago
What makes you assume the root cause was the software ? Perhaps the hardware altimeter was sending errors or the gyroscope was out ? The comet lander Philae bounced and was lost because the hardware harpoons failed to secure it.
AtheistOfFail 10y ago
The issue is an ongoing battle where hardware functions get emulated in software to save costs which just makes the software more complex and error-prone.
3chelon 10y ago
Reminds me of the old joke. If it was a hardware failure, the hardware guys will spend months building models and testing them for stresses and strains and running simulations to find the point of failure. The software engineers will just ask if they can run it again, with breakpoints.
tjxxgkxjt 10y ago
>Is software easier or harder than hardware? Neither. Rather, it's the total lack of design accountability procedures in place for software. When a mechanical or electrical engineer messes up, there is a legal framework in place to hold the involved parties responsible for their actions. Depending on how bad the negligence was, this can include jail time. This motivates those designing the hardware aspect of a product to check and recheck their work many times over, and as a result you rarely read about hardware failures with this level of frequency. In contrast, when a software system fails, everyone seems to just throw their hands up in the air and say how this is par for the course. There is currently no legal PE certification available for software, so we have seen disproportionately many catastrophic software failures.
planteen 10y ago
In my experience, hardware is much more difficult to debug. But my hardware experience is limited to FPGAs, never a full ASIC team. There are nightmarish bugs in hardware associated with things like clock domain crossings, bad timing constraints, and signal integrity. Give me software bugs over that any day!

by dzdt 10y ago

nickpeterson 10y ago

I don't know much in the way of electrical engineering, but I think the complexity possible is fairly close, but its likely easier to judge a hardware design as being sound since it ultimately has to tie back to reality. I think the complexity of software is that it's almost completely abstraction. So the question reminds me of someone asking, "What's harder, physics or philosophy?"

SixSigma 10y ago

> the lander's computer thought it was ... > led the craft to believe it was... Don't anthropomorphize computers, they hate that. As an armchair space explorer, I would have imagined such a crucial part of the mission had serious redundancy.

onion2k 10y ago
I would have imagined such a crucial part of the mission had serious redundancy Redundancy adds either weight if you're computing things on two systems at once, or time if you're recomputing using different code. I'd guess that working out the balance between risk of failure, weight and time is a very complicated problem.
- pixl97 10y ago
  Also redundancy doesn't solve a lot of potential problems. What if your redundant systems disagree? Which one is wrong?
madaxe_again 10y ago
It probably did, and whatever went wrong went wrong across the redundant systems, which is why they're thinking it's a bug. It could be something straightforward that presented an unexpected input and made it behave in an equally unexpected fashion. I'd imagine they're currently replaying the sensor data to an instance on earth and seeing how it responds.
dzdt 10y ago
I think the anthropomorphizing in this case is fine. Someone familiar with programming easily takes "computer thought it was on the ground" as shorthand for "computer began executing subroutines designed to activate when the craft was on the ground." The anthropomorphized version is more concise for someone familiar with and more understandable for someone unfamiliar with the inner details of computer systems.
- andars 10y ago
  I think it was a joke, seeing as SixSigma proceeded to anthropomorphize computers ("they hate that").
  - SixSigma 10y ago
    A bit of both. I actually don't think anthropomorphization is helpful in discussions with the lay public but I'm not that serious about it.

maggit 10y ago

Perhaps it is also a matter of how you fix it. Generally software bugs can be fixed by patching over the Internet, making them less scary, whereas hardware bugs are set in stone. (Stone is mostly silicon, right?) Of course, this is a bit different for software we ship to other planets :P

logfromblammo 10y ago
By mass, stone is mostly oxygen. Silicon is in second place.

user5994461 10y ago

From my experience working across both industries: Software is harder than hardware (generally speaking). The root cause is that hardware has clear purpose and is limited by the real world. An aircraft from 2015 or from 2000 does the same thing: Get you from Point A to Point B, same world, same constraints, same goal. A software that does something today. It doesn't give any clue about what it will be or do in 2-5-10 years. IMO: Software projects are way more ambitious, more complex and evolving faster than hardware. What is expected from software is NOT expected (nor achievable) in hardware at all, that's one of the first thing I noticed. --- Nonetheless, hardware can run software onboard. So you get hardware and software dev projects, both running along. That get some quirks of both world. IMO, the hardware [and real world] limitations will quickly limit the software.

tremon 10y ago

Is software easier or harder than hardware? That's hard to say in general. With current practices, I'd say software is harder to get right, but that is mainly due to a failure to spec correctly. Hardware is engineered with very tight controls: dimensions, shapes, and properties are all produced according to a specification that doesn't just specify its nominal values, but also the acceptable tolerance for any deviations. No software that I know of is engineered to the same level of precision as hardware. The lack of specification-guided tooling (and validation for 3rd-party components) is what puts software development not even in the same league as hardware development.

scrollaway 10y ago
> No software that I know of is engineered to the same level of precision as hardware. Are you counting NASA-produced software? I'm not familiar with ESA's software pipeline but I imagine it's similar.
- tremon 10y ago
  Sadly, I'm not. I truly wish I could say that NASA-produced software is within the range of "software that I know of", but it's not.
jack1243star 10y ago
Computing Needs Time [1], which focuses on the handling of time, is a nice read on this topic from the software point of view. [1] http://digitalassets.lib.berkeley.edu/techreports/ucb/text/EECS-2009-30.pdf http://digitalassets.lib.berkeley.edu/techreports/ucb/text/E...

henrik_w 10y ago

On that subject, I like this quote: "Hardware eventually fails. Software eventually works." -- Michael Hartung

tezza 10y ago

What makes you assume the root cause was the software ? Perhaps the hardware altimeter was sending errors or the gyroscope was out ? The comet lander Philae bounced and was lost because the hardware harpoons failed to secure it.

AtheistOfFail 10y ago

The issue is an ongoing battle where hardware functions get emulated in software to save costs which just makes the software more complex and error-prone.

3chelon 10y ago

Reminds me of the old joke. If it was a hardware failure, the hardware guys will spend months building models and testing them for stresses and strains and running simulations to find the point of failure. The software engineers will just ask if they can run it again, with breakpoints.

tjxxgkxjt 10y ago

>Is software easier or harder than hardware? Neither. Rather, it's the total lack of design accountability procedures in place for software. When a mechanical or electrical engineer messes up, there is a legal framework in place to hold the involved parties responsible for their actions. Depending on how bad the negligence was, this can include jail time. This motivates those designing the hardware aspect of a product to check and recheck their work many times over, and as a result you rarely read about hardware failures with this level of frequency. In contrast, when a software system fails, everyone seems to just throw their hands up in the air and say how this is par for the course. There is currently no legal PE certification available for software, so we have seen disproportionately many catastrophic software failures.

planteen 10y ago

In my experience, hardware is much more difficult to debug. But my hardware experience is limited to FPGAs, never a full ASIC team. There are nightmarish bugs in hardware associated with things like clock domain crossings, bad timing constraints, and signal integrity. Give me software bugs over that any day!