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%.
"Hardware eventually fails. Software eventually works." -- Michael Hartung
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.
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.
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.
Are you counting NASA-produced software? I'm not familiar with ESA's software pipeline but I imagine it's similar.
[1] http://digitalassets.lib.berkeley.edu/techreports/ucb/text/E...
So the question reminds me of someone asking, "What's harder, physics or philosophy?"
> 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.
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.
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.
The anthropomorphized version is more concise for someone familiar with and more understandable for someone unfamiliar with the inner details of computer systems.
I actually don't think anthropomorphization is helpful in discussions with the lay public but I'm not that serious about it.
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.
Of course, this is a bit different for software we ship to other planets :P