Secret features: ethics of developing them

[Aristos Queue]

QUOTE (flarn2006 @ Apr 4 2009, 03:56 PM)

I just believe that software should never have features not revealed to the end users, with the prominent exception of easter eggs. If a file format has a certain feature, the program should allow anyone to use it, not just the developers.

I accept your challenge. I believe that unrevealed features serve more benefit to users than harm, and I suggest that software that does not have such features is likely not innovating sufficiently.

First, let us differentiate "unrevealed features" from both "undocumented features" and "undocumented behavior". Undocumented features are publicly exposed features, such as items in the palettes or menu items, that are undocumented. I am not defending developers who fail to communicate with their tech writers or publishing errors that result in documentation being dropped. It is poor practice to leave the feature hanging out there with no reference for the user who might invoke it. Similarly, undocumented behavior is behavior of public features in edge and corner cases for which no help is available. Common instances of undocumented behavior include the value of the output if the function returns an error, or the behavior of a menu item when the application is in a non-standard mode, or differences in behavior on non-dominant operating systems. These are hard to track sometimes, but nonetheless, they should be documented.

No, when I speak of unrevealed features, I mean things that you need either a special config token or a special license key to access, features that require an input file that can only be generated by hand-editing the file, or features that require a long series of keystrokes to activate (Up, Up, Down, Down, Left, Right, Left, Right, B, A, Select, Start). Some of these features are what we call "easter eggs" -- little surprises that have no effect on how you use the software but are fun to discover, such as "SuperFunkyPrivateSpecialSecretForumStuff=true" in LV 8.5 only. Those are fun, but are not true unrevealed features. No, what I'm talking about is truly useful functionality of software. In LabVIEW, the first item that everyone will list is VI scripting, the ability to make calls into the LV editor that let you make programmatic modifications to a VI. But there are smaller features: custom wires for classes that go way beyond what the dialog will let you edit; plug-ins to the Project Window; password access to certain block diagrams. These are the sorts of features that I am suggesting it is right, well and good* for software to include.

I believe, first of all, that unrevealed features can add to the usability and stability of software. To say that I have made a feature unusable by users for the sake of making the software more usable is not a contradiction of terms. There are plenty of tricks, backdoors, hacks, etc, that can cause myriad problems. For example, LV has an event structure. With this structure, you can catch events fired by the UI. There are private events that are not listed in the structure's configuration dialog. Why? Because some of those events look useful, but if you don't use them right (put too long a process in those event handlers, or use them in parallel with some specific other process), you end up hanging all of LV and having to kill it and restart. Should a regular user see such events listed in the config dialog? I argue no. They are system specific events that are only needed in the most rare of occassions. By exposing them privately, LV is able to write more of its functionality in G code, which means that higher level functions can be easily exposed as subVIs for users' general consumption. If customers are having problems and come to us absolutely unable to solve a problem without a particular event, we may give that particular customer a customized handler for that event. But there is no point to having regular users think they are using something useful, having it hang on them, and then having them believe that LV is somehow inherently unstable. Even burying such things in an "Advanced" pull-right is no help. 19 years of programming has taught me that users will open every menu, will click on every button, and then blame the developer when things go awry. Telling a user "Sorry, you're not advanced" seems to just upset them. It is far better for the collective user experience to to have those users that actually are advanced go hacking through files, trolling through forums, and wheedling insiders for secrets than to put generally useless junk in the interface, even if that junk is extremely useful in the .01% of cases.

Unrevealed features also foster innovation. When a feature is not complete, should LV not ship it until it is finished? Or is it better to ship it behind a config token and then call a few key users up and say, "We think this works, would you give it a try and let us know?" We've gotten a lot of feedback over the years by doing this. Some of you who are alliance members or LV Champions may be reading this and thinking, "What? I've never been asked to test secret features, and that's part of my role as alliance/champion!" Don't get mad -- most of the time it is an individual developer who drops such half-finished features in so they can be used completely within National Instruments. You're not being left out of any secret beta. And, to be perfectly honest, most of the time you guys find such features anyway. It is a hard balance to strike -- users want stable versions of LabVIEW, but they also want development of new features, and they want some way of knowing which features are safe and which are not. On the flip side, NI doesn't want to be maintaining multiple versions of LV simultaneously if we can possibly avoid it -- that's very expensive. So for certain features, this "hide it and take the feedback of those who find it" approach is extremely valuable. If you had to enter a config token by hand, or if a certain node only worked when you dropped it at least 16,000 pixels away from the origin, or if you had to adjust your contrast way way down to even see something in the palettes**, you can be pretty sure that it is not considered to be on the "safe and trusted" feature list.

Finally, unreavealed features show good use of developer time. There are certain operations in LabVIEW that you can trigger from the menus that are complex sequences of operations, and there may not be any way to trigger one of those substeps by itself, or to stop the process midway through. If we took the time to put a nice clean UI on every bit of LV functionality, we'd never ship anything. The rendering system of LabVIEW may use the OpenGL library under the hood, but that doesn't mean we take the time to wrap every OpenGL feature and expose it as a LV VI. The LV Project may be able to register with the OS to get updates when a file changes on disk, but that doesn't mean we take the time to provide a way for a user to register interest in files of theirs. It might be done eventually, or maybe not. Developers spend time on the features they think will be most valuable to users, and along the way they may include any number of smaller features that users have no access to. They may put all sorts of notes in the save format of files to support those features, bits that are not intended for users to twiddle. Providing twiddling access means supporting error conditions, means documentation, means tech support, means time lost to other projects. Sometimes it is better to just leave the feature hidden.

In summary, I believe that unrevealed features support the values of usability, stability, innovation and accelerated development of more valuable features. I would be very interested to hear flarn2006's position on why such features are some combination of wrong, bad or evil*, and what value propistion he/she feels is gained by deliberately minimizing the existence of such features.

* Right/Wrong: is this thing acceptable by some observer's subjective standard; well/bad: is this thing acceptable by its own internal standards; good/evil: is this thing acceptable by some objective standard agreed to by the debating parties.

** To the best of my knowledge, there are no easter eggs hidden at 16000 pixels from the origin or in nearly the same color as the palette background. These are just ways I've thought of over the years to hide easter eggs.

[Val Brown]

QUOTE (Aristos Queue @ Apr 4 2009, 03:35 PM)

I accept your challenge. I believe that unrevealed features serve more benefit to users than harm, and I suggest that software that does not have such features is likely not innovating sufficiently.

....

In summary, I believe that unrevealed features support the values of usability, stability, innovation and accelerated development of more valuable features. I would be very interested to hear flarn2006's position on why such features are some combination of wrong, bad or evil*, and what value propistion he/she feels is gained by deliberately minimizing the existence of such features.

[/size]

I agree with all of what you're saying here AQ except that I have, well, over 25 years of active software development behind me. No wonder I've got grey hair!

Flarn2006 may I suggest that you take a moment, take a breath and then see if you can express what you're really meaning here and what your real intention is with all of your attempts to hack LV. And I'm not opposed to hacking -- been there done that -- esp in looking for undocumented features, "hidden" functionality, etc. If you want to break software, give it to me. I'll find the problems. So I understand that part of what's going on here but I don't think that's the real motivation of what you're doing. And maybe I'm completely wrong on this so I too would really like to hear what you have to say about it.

[bsvingen]

I see a confusion of ethics and reasons here. You can find reasons for everything, and good reasons does not need to be ethically correct. LV is used for many things, some of these things include controlling expensive, dangerous or even vital hardware. In those cases, if you don't have the source code available, the only ethical correct thing to do is to use documented features only. On the other hand, if that software does include undocumented and unrevealed (untested) features, how can users be sure that those features cannot be invoked accidentally? So, The only ethical correct thing to do is to document everything, also unrevealed and untested features. All undocumented features should be removed.

[crelf]

Let's separate the context of this discussion into two groups of software so I can comment intelligibly:

• Product
  This is when you iteratively develop a product over several versions that you then sell (either internally or external). Usually, you sell it to several different customers (although this is not always the case). You develop the requirements based on your own market research. You're not aiming to meet a set of specific requirements from your customers, but more an experience that they want to have. Examples of this include LabVIEW itself. I think that it's perfectly fine for anything to be added and undocumented to products - they're your internal brain-child, and as long as you can sell it to those who sell it to the end customers, then go for it. As you're iterating the product, then you might want to add some sub-features that a future feature will rely on, and not expose those sub-features to the user just yet - perfectly fine (as long as those sub-features don't screw with the expected behaviour of the current version - but that's a topic for another thread).
  
• System
  This is software that you're developing usually to an external customer's specifications. In essence, they tell you what it needs to do, you design and develop it to do so. Examples of this: the one-off test systems that system integrators make, to test a customer-specific UUT in a defined way. The software engineer has latitude in how it is developed, but not what it does - of course, during the requirements gathering stage of the project, any test engineers worth his salt will explore the UUT-specific test world with the customer to help them get the best information (not data) from the system and suggest innovative and appropriate methodologies for getting that information. Systems are a very different kettle of fish from products - you're generally developing on the clock directly for an external customer. If you've got your process right, you'll have well defined and properly written requirements that you shouldn't stray from - the customer is expecting a system that does what they asked for - nothing more, nothing less (if you deliver them less then that's an obvious issue, but if you deliver them more you can get into a lot of hot water too - but that's an issue for another thread).
  

Of course, there are situations where you have hybrids of the product/system models, but that's a topic for another thread. Wow - that's a lot of "another thread" topics

QUOTE (bsvingen @ Apr 5 2009, 07:01 AM)

LV is used for many things, some of these things include controlling expensive, dangerous or even vital hardware. In those cases, if you don't have the source code available, the only ethical correct thing to do is to use documented features only.

Right - and I think, in this case, that is the responsibility of the end-user. If you know that you're using undocumented features (and, truth be told, we usually do because we've gone digging for them), then you're introducing a risk. It's not NI's fault that you chose to use them - it's yours. That said, I use undocumented features in my architectural designs all the time - I know that they're risky, but I also use them for their feature pay-off. It's my risk, and I'm willing to take it.

QUOTE (bsvingen @ Apr 5 2009, 07:01 AM)

The only ethical correct thing to do is to document everything, also unrevealed and untested features. All undocumented features should be removed.

*shaking head* No, no, no. Well, yes if you're talking about a system, and no if you're talking about a product

This argument has little to do with ethics. LabVIEW will do what it's documented to do. If you don't want to take the risk of using undocumented features, then don't use them - stay within the bounds of the documented ones. It's your choice. Having NI remove all the undocumented ones is ludicrous. I assume that the amount of work that would be required to fully document them all is ridiculous, and if they tried to remove them all then the documented ones would be crippled (there are plenty of documented features that rely on undocumented features). Irrespective of your position on whether you think it's an ethical argument or not (which, as an aside, I don't) then the practical end point you're pushing for is an end to LabVIEW. So, if you want to continue the discussion intelligably, then I suggest you make it a theoretical discussion about software in general, or discuss a specific system of your own (but then you get into the product vs system dichotomy I mentioned above).

[bsvingen]

QUOTE

This argument has little to do with ethics. LabVIEW will do what it's documented to do.

Actually this is the essence of the ethics. A similar situation would be a turbojet engine with an undocumented/unrevealed feature that boosted output by 50% - at the expense of greatly increasing the probability of cathastrophic failure (this feature could be implemented in software within one of the engine controllers). If the feature is there, then it should be documented, othervise it should be removed. Let say I used LV to program the embedded controller, then everything about that controller must be documented, and using software that I know include tons of undocumented/unrevealed features is simply not an option.

Often making sure that the unexpected does not happen, is much more important than simply making it work as expected. In most industries this is the rule, not the exception.

[crelf]

QUOTE (bsvingen @ Apr 5 2009, 12:30 PM)

A similar situation would be a turbojet engine with an undocumented/unrevealed feature that boosted output by 50% - at the expense of greatly increasing the probability of cathastrophic failure (this feature could be implemented in software within one of the engine controllers).

I don't think that's anything to do with the ethics of the company that developed the engine. To make it boost it's output by 50% (just like if you use any of the undocumented features in LabVIEW) you would have to go hunting for them. Essentially, you're using the product outside of what you were told will work, so you're assuming the risk of using an undocumented feature. One of my mantras is "Just because you can, doesn't mean you should", and if you're working with undocumented features of *anything* then the risk is yours, and yours alone.

Another example - you buy a hammer and then crush someone's skull in with it. Can you say the hammer manufacturer is to blame because you used the hammer for a purpose for which it wasn't designed? I sure hope not, although some days it seems that is the direction the world is going

[Jim Kring]

QUOTE (crelf @ Apr 5 2009, 10:04 AM)

Another example - you buy a hammer and then crush someone's skull in with it. Can you say the hammer manufacturer is to blame because you used the hammer for a purpose for which it wasn't designed? I sure hope not, although some days it seems that is the direction the world is going

Oh, you mean like the http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act' rel='nofollow' target="_blank">DMCA?

[crelf]

QUOTE (Jim Kring @ Apr 5 2009, 01:22 PM)

Oh, you mean like the DMCA?

That's exactly what I was thinking about while I was typing that Specifically, the linking to infringing content.

[Jim Kring]

QUOTE (crelf @ Apr 5 2009, 10:39 AM)

That's exactly what I was thinking about while I was typing that Specifically, the http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act#Linking_to_infringing_content' rel='nofollow' target="_blank">linking to infringing content.

By suggesting that infringed content might exist and there could be links to it, you are enabling others to find it and could be liable for aiding the infringement.

[crelf]

QUOTE (Jim Kring @ Apr 5 2009, 01:58 PM)

By suggesting that infringed content might exist and there could be links to it, you are enabling others to find it and could be liable for aiding the infringement.

Yep - you might as well call me thepiratebay

[Val Brown]

QUOTE (Jim Kring @ Apr 5 2009, 10:58 AM)

By suggesting that infringed content might exist and there could be links to it, you are enabling others to find it and could be liable for aiding the infringement.

And that's the difference between American and most of the rest of the civilized world. In America you can ONLY ski in the "approved" areas because, otherwise, the management of the ski resort can be held liable EVEN IF you trespass in defiance of posted signs and ski in declared "unsafe" r "out of bounds" areas. In other parts of the world you are on your own lookout and are expected to ask responsibly -- eg not throw the toaster into the bathtub to have toast while taking a bath.

The extent of that way of thinking would be to presume that ALL potential features had to be exhaustively discovered, fully documented, as well as recommendations for/against their use detailed (esp in unpredictable fashions). It's really pretty absurd to think that ANY product could be so controlled in its development, esp when it's software. But, then again, all of this is really being driven by the US legal system and its culture. And, as the "joke" goes, American justice is the best that money can buy.

[BobHamburger]

I feel that all this stuff about ethics and culpability, while certainly interesting, only obfuscate the subject. I have a completely different and much simpler perspective on this issue...

Much of the traditional software world does not consider LabVIEW to be a "real" programming language, for a variety of reasons. Paramount in many of the arguments that I've heard is this simple test: can you write LabVIEW in LabVIEW? Well, if you include scripting and other related features in all their gory, er, I mean, glory, then the answer is yes. If you exclude them, the answer is no. Scripting etc. completes the language, plain and simple. To continue to withold these from general distribution is to deny allowing the language to fully mature.

[Justin Goeres]

QUOTE (bsvingen @ Apr 5 2009, 08:30 AM)

I used LV to program the embedded controller, then everything about that controller must be documented, and using software that I know include tons of undocumented/unrevealed features is simply not an option.

You're equivocating. Earlier in the thread you said "The only ethical correct thing to do is to document everything, also unrevealed and untested features. All undocumented features should be removed." Now you're saying that you can't (won't/shouldn't) use software with "tons of undocumented features." Which is it? None, or just less than "tons?"

If "none" is what you really meant, I would suggest you put down the mouse, shut off the computer, and go find a new profession that doesn't involve computers in any way. Your operating system, your web browser, your word processor, and any reasonably useful development tool you can think of have hundreds, if not thousands of undocumented features. To say that this somehow implies that the entire software development world is fundamentally unethical strikes me as a rather novel idea.

Either that or you're one of the most talented trolls ever to grace this forum .

[Val Brown]

QUOTE (BobHamburger @ Apr 5 2009, 05:12 PM)

I feel that all this stuff about ethics and culpability, while certainly interesting, only obfuscate the subject. I have a completely different and much simpler perspective on this issue...

Much of the traditional software world does not consider LabVIEW to be a "real" programming language, for a variety of reasons. Paramount in many of the arguments that I've heard is this simple test: can you write LabVIEW in LabVIEW? Well, if you include scripting and other related features in all their gory, er, I mean, glory, then the answer is yes. If you exclude them, the answer is no. Scripting etc. completes the language, plain and simple. To continue to withold these from general distribution is to deny allowing the language to fully mature.

Ah, let's make certain to compare apples to apples and oranges to oranges. LabVIEW is a product, made by a single company, released under certain conditions. C/C++ is a standard, used by many companies to produce many different compilers. The product doesn't produce itself, it is produced. The standard is self-replicating/implementing.

Now should/could LabVIEW actually be released as "G" perhaps both a product and a standard? That's an interesting question and one that, I'm sure, NI has discussed internally. At this point we all know there answer.

If I'm not mistaken, the standard of "can you write X in X?" really only applies to standards, not to products.

[bsvingen]

QUOTE (Justin Goeres @ Apr 6 2009, 04:21 AM)

You're equivocating. Earlier in the thread you said "The only ethical correct thing to do is to document everything, also unrevealed and untested features. All undocumented features should be removed." Now you're saying that you can't (won't/shouldn't) use software with "tons of undocumented features." Which is it? None, or just less than "tons?"

If "none" is what you really meant, I would suggest you put down the mouse, shut off the computer, and go find a new profession that doesn't involve computers in any way. Your operating system, your web browser, your word processor, and any reasonably useful development tool you can think of have hundreds, if not thousands of undocumented features. To say that this somehow implies that the entire software development world is fundamentally unethical strikes me as a rather novel idea.

Either that or you're one of the most talented trolls ever to grace this forum .

The point is: You wouldn't use Google Chrome and a $500 laptop as a controller for the space shuttle even though it can be done It all depends on what you are doing. If you are simply "writing software", nobody cares about documentation of the compiler as long as the software works as intended. If you work as a consultant in engineering, you have no liability what so ever for the results you produce, and can use whatever software you choose. But if you produce and sell controllers for power plants, biochemical factories, car engines etc, you can be held responsible, at least in part if the controller faults due to any error (software or hardware). If it turns out that the error happened because of unrevealed/undocumented features, and you knew that the compiler had tons of them without saying anything, you are most likely in deep sh*t.

Another point is that now we know that NI is shipping software with lots of undocumented and unrevealed features consisting of random snippets of code from arbitrary software engineers, most likely with little or no experience in any real life industry at all. In fact, it is so much of it that it would be too expensive to either remove it or document it. I understand that this practice allows a faster development paste, but this is purely a pragmatic reasoning. I mean, open source software allways has a "stable" branch that is fully "documented" (open) and does not contain experimental code. Any changes done there is to fix bugs. The experimental code is reserved for "nightly builds" and betas, but at least it is documented. What NI is doing is to include the experimental code in the stable branch with no documentation what so ever because the source is closed. I would prefer the open source way. IMO that is much better ethics.

[crelf]

QUOTE (bsvingen @ Apr 6 2009, 04:56 AM)

...open source software allways has a "stable" branch that is fully "documented" (open) and does not contain experimental code.

Herein lies the root issue: you are confusing undocumented and experimental. They are not necessarily the same.

[Justin Goeres]

QUOTE (bsvingen @ Apr 6 2009, 12:56 AM)

The point is: You wouldn't use Google Chrome and a $500 laptop as a controller for the space shuttle even though it can be done

But that has nothing to do with the issue of whether Google Chrome has undocumented features. It has to do with the fact that Google Chrome, from a technical standpoint, doesn't have the capabilities to accomplish the task at hand. (Unless one of those "undocumented features" is "continuous monitoring and control of thousands of sensors and actuators, with multiple levels of redundancy and guaranteed real-time access.")

QUOTE

software", nobody cares about documentation of the compiler as long as the software works as intended.

I write "software" and I care about documentation of the compiler a lot.

QUOTE

If you work as a consultant in engineering, you have no liability what so ever for the results you produce, and can use whatever software you choose. But if you produce and sell controllers for power plants, biochemical factories, car engines etc, you can be held responsible, at least in part if the controller faults due to

any

error (software or hardware). If it turns out that the error happened because of unrevealed/undocumented features, and you

knew

that the compiler had tons of them without saying anything, you are most likely in deep sh*t.

I don't think that's relevant. In any significant hardware system with serious safety risks like you've mentioned, the hardware must always fail to a safe state. A well-designed system will do this without the software being involved. So the idea of whether the software has "unrevealed/undocumented features" is moot, because a good hardware design specifically assumes that's the case and works around it.

QUOTE

Another point is that now we know that NI is shipping software with lots of undocumented and unrevealed features consisting of random snippets of code from arbitrary software engineers, most likely with little or no experience in any real life industry at all.

I think that NI would strongly disagree with that (although I can't speak for them specifically). The features aren't "random," the software engineers most surely aren't "arbitrary," and you have no idea about their industry experience.

QUOTE

In fact, it is so much of it that it would be too expensive to either remove it or document it. I understand that this practice allows a faster development paste, but this is purely a pragmatic reasoning. I mean, open source software allways has a "stable" branch that is fully "documented" (open) and does not contain experimental code. Any changes done there is to fix bugs. The experimental code is reserved for "nightly builds" and betas, but at least it is documented. What NI is doing is to include the experimental code in the stable branch with no documentation what so ever because the source is closed. I would prefer the open source way. IMO that is much better ethics.

In terms of shipping a product, I usually prefer pragmatism over ideology, so I guess it doesn't bother me. To each his own.

[Val Brown]

QUOTE (bsvingen @ Apr 6 2009, 01:56 AM)

...I would prefer the open source way. IMO that is much better ethics.

At many different times, in many different threads we return to this fundamental paradigm issue. Some are just very committed to open source and seem to believe that the world would be a far, far better place, in all kinds of ways, if ONLY all code were open source. First of all I don't have that kind of belief but, perhaps more importantly (because after all who am I?) NI doesn't have that belief, not does Microsoft. And IMO there are very good reasons for them to not have that belief. As the saying goes: If you can't stand the heat, stay out of the kitchen. So, if your really don't like the ethics of non-open source software, shift all of your code away from ANY form of software from NI.

[Aristos Queue]

QUOTE (BobHamburger @ Apr 5 2009, 07:12 PM)

can you write LabVIEW in LabVIEW? Well, if you include scripting and other related features in all their gory, er, I mean, glory, then the answer is yes. If you exclude them, the answer is no.

If you exclude them, the answer is still yes. It's just not as easy. But it can be done.

[PJM_labview]

QUOTE (Aristos Queue @ Apr 6 2009, 09:21 PM)

If you exclude them, the answer is still yes. It's just not as easy. But it can be done.

On can argue that this is pretty much restricted to NI employee that are familiar with the VI (and all its siblings) file format.

[shoneill]

QUOTE (Aristos Queue @ Apr 7 2009, 05:21 AM)

If you exclude them, the answer is still yes. It's just not as easy. But it can be done.

With the documentation as shipped as the only source of information?

Seems unlikely to me but perhaps, perhaps.

Shane.

[Val Brown]

QUOTE (shoneill @ Apr 7 2009, 12:00 AM)

With the documentation as shipped as the only source of information?

Seems unlikely to me but perhaps, perhaps.

Shane.

Hmmm, sounds like another "contest" may be birthing....Who wants to be the first to demonstrate or refute this? And, perhaps more importantly, why would you REALLY want to do it?

[jzoller]

QUOTE (Aristos Queue @ Apr 6 2009, 10:21 PM)

If you exclude them, the answer is still yes. It's just not as easy. But it can be done.

Perhaps Aristos means in the http://en.wikipedia.org/wiki/Turing_complete' rel='nofollow' target="_blank">Turing complete sense. That's a long road, though.

Joe Z.

[ggatling]

QUOTE (bsvingen @ Apr 6 2009, 03:56 AM)

...open source software allways has a "stable" branch that is fully "documented" (open) and does not contain experimental code. Any changes done there is to fix bugs. The experimental code is reserved for "nightly builds" and betas, but at least it is documented. What NI is doing is to include the experimental code in the stable branch...

Here here! I have long opposed NI's practice of adding horrible buggy code into the Latest, Greatest release together with all the bug fixes for the previous version. I feel certain NI's current release schedule is driven by a business model that does *not* center around releasing an amazingly powerful, undeniably stable software product. That being said, LabVIEW is still the best tool for my job, so I make do.

(Clearly still licking my wounds from 8.0)

[bsvingen]

QUOTE (Justin Goeres @ Apr 6 2009, 04:08 PM)

I don't think that's relevant. In any significant hardware system with serious safety risks like you've mentioned, the hardware must always fail to a safe state. A well-designed system will do this without the software being involved. So the idea of whether the software has "unrevealed/undocumented features" is moot, because a good hardware design specifically assumes that's the case and works around it.

This is not true at all. Modern digital controllers control whole systems in a way that is impossible in a "fail safe" mode. There are no fail safe mode, either it works or it doesn't. The actuators themselves cannot be operated without proper digital signals, except in service/testing mode. Whole system are designed to be controlled digitally, and there is no other way to control them. There are two main reasons for this. One reason is that statistics show that computerized control is more fail safe than any other alternative (mechanical or electric). The other reason is that digital control enables the processes to run much more efficient because they are pushed far beyond what previously would be called a safe, or even operational state. Take for instance the fuel injection in any ordinary modern car (common rail TDI). If the controller shuts down, the engine stops in the same manner as if the crank broke, but this is an unproblematic event (for anyone except the driver ). A much bigger problem occurs if the controller does something wrong, like too much fuel, uneven fuel distribution, too much boost etc due to a software error. This would be the same as if the crank suddenly would change the relative angles of the pistons (not that it is possible, but it would produce similar problems).

All larger modern ships are controlled "by wire" with very sophisticated, almost AI-like navigational and maneuvering systems using GPS, radar, ultrasonic sensors, inertia sensors etc, most of them don't even have steering wheels, and those that do have it for show. A software error due to some hidden and undocumented experimental feature for the reason of "testing" something new, is completely out of the question. Airbus air liners use fly by wire, and has done so for decades already. It uses a system with several computers working in parallel, and there is no manual or mechanical backup whatsoever.

The point is, computerized control is as much a part of a system as the crank shaft is a part of an engine. The same reliability and quality is expected of the software in those controllers as is expected of the alloy content in the pistons, or the structural integrity of the ship's hull, or the main beams of the wings. Undocumented and unreleaved features in the software is as expected and assumed as you would expect to have part of the ship being secretely made of some unknown experimental paper foil because one of the engineers had a "bright" idea.