Secret features: ethics of developing them

[Val Brown]

QUOTE (bsvingen @ Apr 11 2009, 02:08 AM)

You are missing the point (at least half of it). The behavior is not the issue, the quality is. More presisely you want to get rid of all possibilities for unexpected things to happen, at least as much as you can. It is about failure modes, not validation of operational modes.

Testing of a system and documenting (defining) its subsystem are two different things. Testing a system consisting of undocumented sub systems will still leave you with an experimental system. This is a simple fact.

Something tells me some of you just don't get it (no offence ) Without stretching the similarity too far, minimizing failure modes is somewhat similar to minimizing the possibility of bugs entering the code. In this respect LV already is way beyond most other compilers. It is also somewhat similar to the reasons for encapsulation (and OOP). You simply cannot expect the unexpected, but you can minimize the possibility of unexpected things to happen by assuring everything is well defined, minimizing side effects and by reusing things you know have no failure modes. Is it possible to be (reasonably) sure that things are well defined without documenting it so other people can look at it, or at least leave the source open? I doubt it.

I think YOU "just don't get it". NOT using undocumented features means, among other things, "assuring everything is well defined, minimizing side effects and by reusing things you know have no failure modes". In other words, do use/reuse undocumented features UNLESS you are clear in what they will and won't do and you have validated all of that with specific unit testing, etc procedures.

Your last point really says it all IMO: "Is it possible to be (reasonably) sure that things are well defined without documenting it so other people can look at it, or at least leave the source open?" The answer is: Yes and, if not, then don't use it; and validate that by your own systematic testing program regardless. It also sounds like this is another plea for LV to be open source based on the belief that open source is inherently "better" than code that is not open source (such as LV). If that is what you truly believe, then why are you using LV? How do you rationalize that your behavior -- in using LV -- contradicts what you're posting here?

[jdunham]

QUOTE (bsvingen @ Apr 11 2009, 02:08 AM)

You are missing the point (at least half of it). The behavior is not the issue, the quality is. More presisely you want to get rid of all possibilities for unexpected things to happen, at least as much as you can. It is about failure modes, not validation of operational modes.

Well my point still stands. What is the difference between LabVIEW having undocumented features versus running LabVIEW on an OS with undocumented features? In reality, it's just a bunch of ones and zeros running through a von Neumann machine. Since we are well past the days where any person or team can make a useful and affordable computing device with no outside help, there is probably no way to eliminate the possibility of undocumented features.

The rest of us understand that presence or lack of undocumented features is not a useful metric of quality in a computing system, because no one has any way to count the undocumented features in the silicon, the os, the drivers, the labview etc, and of which could and maybe do have an impact on reliability. Since you can't even know how much there is, and since plenty of reliability problems (crashes) stem from documented features, it's surely pointless to worry about undocumented features.

[Aristos Queue]

Jdunham and bsvingen: Is there a difference -- in your opinion -- between unrevealed features in the editor, unrevealed features in the runtime engine and unrevealed libraries of VIs? Because your arguments (and I'm still contemplating their validity) only have applicability to unrevealed features in the runtime engine itself, and there are damn few of those (I am not sure I can think of any to be honest, but I'll keep trying to think of them). In other words, that which you use, you use, and is documented, and your final application has no reliance on unrevealed things. Does that lessen your objections?

[jdunham]

QUOTE (Aristos Queue @ Apr 12 2009, 06:40 PM)

Jdunham and bsvingen: Is there a difference -- in your opinion -- between unrevealed features in the editor, unrevealed features in the runtime engine and unrevealed libraries of VIs? Because your arguments (and I'm still contemplating their validity) only have applicability to unrevealed features in the runtime engine itself, and there are damn few of those (I am not sure I can think of any to be honest, but I'll keep trying to think of them). In other words, that which you use, you use, and is documented, and your final application has no reliance on unrevealed things. Does that lessen your objections?

Well I must not have been clear enough. I don't have any problem with unrevealed features. My point was that if someone considered that a serious problem, then any modern combination of silicon, OS, Compiler (which created LabVIEW.exe) and LV Runtime or any other app would be off-limits. I don't think you could ever predict all possible CPU execution paths in anything running on Windows.

[bsvingen]

QUOTE (Aristos Queue @ Apr 13 2009, 02:40 AM)

Jdunham and bsvingen: Is there a difference -- in your opinion -- between unrevealed features in the editor, unrevealed features in the runtime engine and unrevealed libraries of VIs? Because your arguments (and I'm still contemplating their validity) only have applicability to unrevealed features in the runtime engine itself, and there are damn few of those (I am not sure I can think of any to be honest, but I'll keep trying to think of them). In other words, that which you use, you use, and is documented, and your final application has no reliance on unrevealed things. Does that lessen your objections?

Yes it does.

[Val Brown]

QUOTE (bsvingen @ Apr 13 2009, 01:43 AM)

AQ:>In other words, that which you use, you use, and is documented, and your final application has no reliance on unrevealed things. Does that lessen your objections?

Yes it does.

And this COULD be made clear through thorough "unit testing" throughout the development cycle.