Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently working some testing for a particular area of an application. I had to write some automated tests for a particular feature but due to the circumstances, this was not easy to do. When I asked one of the other testers about it, he mentioned that the same features exist in a sister application our company produces but isn't documented anywhere (end-user documentation or otherwise). He also said that the feature doesn't typically get tested at all in the sister application and isn't usually tested in the application I work on. Apparently this feature isn't heavily used but removing it would require a fair bit of work so the benefit-cost ratio doesn't work out.

All of this has left me with some questions. Other than "The documentation says so" or "We told the client it is", what usually makes a feature "supported" versus an unsupported feature?

share|improve this question

4 Answers 4

what usually makes a feature "supported" versus an unsupported feature?

Commitment by the developer. If some program happens to be able to import XML but the developer doesn't plan to support that feature going forward, users should expect it to break at any moment, or not to work at all. On the other hand, if the developer says that the feature is supported, users can expect that feature to be tested and to work properly. If the feature doesn't work, users can rightly complain that the software doesn't do what the developer says it does.

share|improve this answer
    
True, but your answer infers that if a developer supports a feature, they will always do so. A developer could, at any time, say "I no longer support the use of the software to import XML". They would likely see pushback from users, but "support" for a feature is not guaranteed to be in perpetuity; it is at best indefinite ("for the foreseeable future"). –  KeithS Sep 4 '12 at 19:41
    
@KeithS I certainly don't mean to imply anything like eternal reliability. Users can expect features to work for as long as they're supported; developers can and often do drop support for features and/or add support for features from one version to the next. –  Caleb Sep 9 '12 at 3:45

Supported can mean anything from, we have full ISOxxxx accreditation for that fully tested feature which all our customers are using - through to - we think an intern worked on that a couple of years ago.

Unsupported can mean anything from, we haven't yet received full ISOxxxx accreditation for that fully tested feature which all our customers are using - through to - we think an intern worked on that a couple of years ago.

share|improve this answer
    
While mildly humorous, this isn't helpful. There is a dividing line and a clear difference between supported and unsupported, being that whoever is responsible for the correct behavior of the software asserts it should work correctly. –  KeithS Sep 4 '12 at 19:38
    
And, apart from perhaps the Space Shuttle, how many pieces of supported software is guaranteed to work correctly? –  Martin Beckett Sep 4 '12 at 19:39
    
Define "guarantee". Chris Farley said it best in Tommy Boy: "You want me to take a dump in a box and mark it guaranteed, I will. I got spare time". In software, there's "if it fails, we'll fix the problem and your data, and give you a free upgrade", and there's "this software will not fail, no way, no how, we've proven it with 10 years of exhaustive testing, we won't even say what we'll do if it fails because it's mathematically impossible". The former is what you get when you pay $100 for a piece of software. The latter is what you get when you pay $100 billion for a piece of software. –  KeithS Sep 4 '12 at 19:52
    
@KeithS - yes, my point was that the Venn diagram for the meaning supported and unsupported is pretty much a circle! –  Martin Beckett Sep 4 '12 at 19:57
    
... with regards to "will it work correctly", yes. With regards to "will the manufacturer make it right if it doesn't work correctly" there is still a clear line between "supported" and "unsupported". –  KeithS Sep 4 '12 at 19:59

I usually take "supported" literally: It means the responsible party (programmer/group/company) intends to support users of the feature when they encounter problems with it. Support can be in the form of direct help, debugging, releasing bug fixes, providing documentation, etc. On the other hand, "Unsupported" tends to mean 'it may work, but don't complain to us if something goes wrong.'

share|improve this answer

A feature is "supported" if the party responsible for the software's overall functionality asserts and takes responsibility for the correct behavior of the software when used in that particular way.

Think of it kind of like a prescription or OTC drug. The maker of that drug designed and intended it to have certain primary effects, targeting a certain "problem" (disease, syndrome, disorder, etc). However, doctors and patients may find that it has certain "side effects" which may actually be desirable. Diphenhydramine (Benadryl) was originally developed and marketed as an antihistamine, combating nasal allergies and other general histamine reactions. It was quickly discovered that it had the side effect of causing drowsiness. That's considered detrimental to a drug intended to be taken during the day, but both not having a runny nose and being drowsy is beneficial to getting a good night's sleep, so the drug began to be included in "PM" formulations of popular painkillers, pretty much solely for the sleep-inducing side effect. It's even in at least one drug that is intended 100% to be a sleep aid (Unisom). Nowadays with the introduction of "non-drowsy" OTC antihistamines, diphenhydramine is almost as commonly used as a sleep aid than as an antihistamine; the major remaining uses of it in its original intent are in children's medicines. In contrast, there are side effects that doctors have seen as beneficial, or diseases that show improvement with the medication, that weren't the drug maker's intent. Until the drug maker goes through the approval process with the FDA for this new use, the drug maker may not market the drug to doctors as being useful for this condition, and does not have any liability for damages as a result of this "off-script" use. Doctors can still prescribe it - they can prescribe pretty much anything for anything - but they carry full liability for any ill effects or other failure.

Software is similar (but without FDA oversight or drowsiness, dry mouth, heart attack, stroke, coma, death or halitosis). The product owner may have designed a piece of software to fill a certain specific need. Users of the software may then find that if you set it up a certain way, it does this other useful thing. The project owner may never have expected that, and in fact may consider it a bug. As such, they may not "support" the software being used in that way; if it fails to perform correctly in that configuration, the user is not entitled to the benefits of any warranty, nor will the developers try to fix the "problem". On the other hand, if that alternate usage is considered beneficial, the programmers may include that functionality, planning for it, testing its correctness and asserting that it will indeed perform correctly when used that way; they now "support" that usage.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.