On Monday, December 10, 2012 4:53:16 PM UTC-8, son_of_flubber wrote:
We tend to focus on ease of use, function and support when we select a flavor soaring software. But what about reliability and robustness? It seems entirely possible to be mislead by erroneous output from a digital adviser. For example, the glider computer might erroneously advise that you have enough altitude to make an upwind transition of a ridge.



Many software programs will work flawlessly most of the time, only to fail when tested at a "boundary condition"; an unusual set of conditions exposes an underlying defect in the code.



1.Does anyone have any true life cases of bad information being provided by a digital assistant in the air?



2.Assuming that a piece of software works most of the time, having more users, using the software for more hours, under a greater variety of conditions, increases the possibility of finding a hidden defect. Once the defect manifests, it still has to be recognized and reported. How many people use each variety of gliding software? Would that correlate with robustness?



3.One of the drawbacks of adding features or fixing defects in a program is the 'rule of unforeseen consequences'. The new feature or bug fix might have the side effect of introducing new hidden defects. Every time a new version of software is released, the confidence level in that software should be reset or at least lowered. We often assume that a new version will be more reliable and that everything that used to work will still work. That is usually true when software goes from alpha to beta version, but mature software can suddenly be broken by a new release. Soaring software is edging into the zone of precarious maturity.



Now that a number of soaring programs have implemented a rather broad menu of features, I would love for a development team to stop introducing new features and instead focus on increasing the reliability and robustness of the software, and thereby increase the justifiable confidence in the software.



An open source software project like XCSoar is in a good position to do this, because the developers are only paid in kudos, glory, and self-satisfaction. (There is no revenue stream to maintain). There are proven techniques for finding hidden defects, for example 1)Code inspection 2)Functional testing 3)Exhaustive model-based automated testing.



Adding new features is sexy and fun while inspecting code and testing is the opposite. It's too bad really, because one day a hidden software defect is going to lead to a fatal pilot error.

I'm still using XCSoar 5.2.4, because it has everything I NEED, and runs with Stone-Axe reliability on my iPAQ 3950, which is STILL the best display in sunlight I've seen yet.