Talk:Software feature

Old section with no original title

This is totally irrelevent, subjective, and (although verifiable) certainly not industry-wide. —Preceding unsigned comment added by 138.16.30.126 (talk) 05:26, 4 February 2009 (UTC)

OR as feature, not bug

There are cases on Wikipedia where one encounters an article which is reticent to a fault, and in so being, achieves a complete failure of expository purpose.

I'm in the camp where I prefer salvageable OR over a complete failure of mandate.

Now, the reason I didn't simply post the following screed is because it's highly dependent on my choice of concrete example (text processing). But everyone here is using a script. Text is Wikipedia's core interface, and is thus surely of universal cognizance.

It's also a primordial example in the annals of computer science of cultural parsimony, and the tremendous complexity burden of finally escaping cultural parsimony (also known as Eurocentrism, or worse).

My contribution here is fire and forget. I have no further vested interest in what happens to this text (whether it makes it into the present article in any form whatsoever).

My goal is simply to stimulate future editors to recognize in concrete terms just how lame the present article really is in its communicative ambition and scope.

Draft vulture smorgasbord

Proposed section heading: Perceptions of feature richness

preexisting text

A YU is said to be feature-rich when it has many options and functional capabilities available to the user. Progressive disclosure is a technique applied to reduce the potential confusion caused by displaying a wealth of features at once.

additional text

Features in software range from core functionality, to convenience, to software eye candy.

An example of a core functionality is being able to handle the full Unicode character set, as opposed to plain ASCII. ASCII-only systems are of limited utility in countries where the dominant language uses a non-Roman alphabet writing system (such as the Cyrillic alphabet or Chinese ideograms) and awkward when employed countries such as the Czech Republic whose Roman-based alphabet contains many accented characters not supported in plain ASCII: ábčďéěchíňóřšťuúůýž.

In countries with extended Roman alphabets, whether limping along in plain ASCII is considered a core feature or a luxury is to some extent a cultural norm. As software technology as become more sophisticated, it is increasingly considered unacceptable for the software to lack full support for regional writing systems (these considerations belong to a feature dimension known as software localization).

To further complicate matters, an application can be partially localized, in allowing users to input and store text in their regional writing systems, while providing a user interface entirely in English, requiring users of the software to be sufficiently fluent in English to at least get by. User interface elements with natural language embedded include dialogue box field labels, error messages, and help text. Supporting all the scripts of the world is largely a programming issue (one which contributes to code complexity and code bloat). Providing a localized user interface in multiple target languages requires employing profession translators or localization service houses.

Few users wish to use every language of the world, but every language of the world has some users. (Wikipedia is itself extensively localized, at great collective effort.)

From the perspective of the programmers, ASCII provides several benefits: the representation of each character is small (so the coding efficiency is good), and the represention is fixed in size (so fast random-access string processing algorithms can be employed). No version of Unicode has both of these properties (it's either large and fixed with, or small and variable width).

To a unilingual speaker of the English language, full Unicode support can almost be viewed as a detriment, not a feature (encoded character strings will either be slower, or more bloated).

But Unicode also provides many standard typographic symbols not found in ASCII, but commonly used in English language orthography (such as the mdash and the ndash and the various fancy quotes used in formally typeset text).

As computers became more powerful, the economic penalty associated with full Unicode support declined, until even people who were originally well served by plain ASCII would come to regard Unicode support as an essential feature, if merely to facilitate information interchange with non-English populations in an increasingly networked world. Further software features at the level of text support: control over collation (for example, see Mac and Mc together), spell checking, hyphenation, and stemming in full-text search (see query expansion).

Natural language text support is, by itself, already a very large feature space. Every aspect of this is needed by some user somewhere in the world, but no end user anywhere comes close to needing full language support for every language in the world strictly for their own purposes. (A giant enterprise such as Google search with a mandate to index all of the world's information surely does hit upon the vast majority of this feature space.)

Thus the conception of feature-richness and software bloat is highly contextual. There are many circumstances where an excess of features is seen as a bad thing, especially where the features visibly interact in the software usability domain (and the interface ends up presenting a great deal of clutter to support tasks the user is not currently using, and might never use at any future time).

Design-centric corporations like Apple Inc., FogBugz and Medium (website) promote themselves as investing heavily in finding an ideal balance for the majority of their users, one which prioritizes remaining lean and singular in focus over being broadly applicable for all users in all contexts (derided by those who prefer this approach as doing everything, but none of it well).

At the other end of the spectrum lies feature creep and software bloat. Bloat is sometimes due to poor implementation, as opposed to supporting an excess feature space.

Another perspective on feature balance is the concept of generativity as adapted by Jonathan Zittrain: "the ability of a technology platform or technology ecosystem to create, generate or produce new output, structure or behavior without input from the originator of the system." The idea here is that no system should excise features in the service of parochial parsimony if this compromises the ability of the next generation of engineers to build more sophisticated systems, using the previous generation of systems as building blocks.

This is a larger conception of the Unix philosophy which dates back to the early days of the computer revolution: that one should build simple, single-purpose tools which can be composed together in powerful combinations, without any one tool become excessively feature laden. This principle has proven to be extremely powerful where applicable, though it primarily appeals to people with an aptitude for writing software.

At the extreme end, the programming language Lisp is famous for having essentially no syntax at all. Even among computer programmers drawn to mathematical minimalism, many find the syntactic parsimony of Lisp unappealing. Because Lisp code lacks extraneous surface features, it can be manipulated and repurposed with surprisingly little effort for almost any purpose. This is highly attractive in exploratory programming projects, where the final scope of the system has an emergent character, though few applications delivered to industry require this extreme degree of flexibility or fluid customization.

An intermediate solution is to use a generalist language such as Lisp (or one of Lisp's many progeny) to implement a domain-specific language (DSL). The purpose of a DSL is to provide precisely the feature set demanded by the application (and very little else), with the least possible syntax, while keeping the syntax human readable.

Software eye candy is where the software provides visually rich UI elements such as animated progress bars which enhance the user experience, but are not core to the functionality provided.

Features are often provided in order to encourage people to use an unfamiliar system which might otherwise seem cumbersome or a chore. Sometimes people with a fetish for feature minimalism neglect the sociology of software adoption. These are features which primarily exist in the dimension of human psychology. For this reason, software system design is often contorted to make the software appear more similar to the older systems it strives to displace, thus decreasing the perception of a barrier to entry for new trainees. Apple Inc. under Steve Jobs became particularly well known for its skeuomorphic design philosophy. Eventually, however, the electronic implementation often grows to become more familiar than the technology of yesteryear, and skeuomorphic design begins to seem like an affectation rather than a feature to the generation of users who grow up using current technology.

— MaxEnt 17:40, 7 October 2018 (UTC)

TL;DR ... and huh? Stevebroshar (talk) 14:33, 7 April 2024 (UTC)

Did you know nomination

The following is an archived discussion of the DYK nomination of the article below. Please do not modify this page. Subsequent comments should be made on the appropriate discussion page (such as this nomination's talk page, the article's talk page or Wikipedia talk:Did you know), unless there is consensus to re-open the discussion at this page. No further edits should be made to this page.

The result was: rejected by BorgQueen (talk) 13:45, 20 February 2023 (UTC)

(

• Comment or view
• Article history

)

• ... that some experts assert that design by committee can lead to an excessive accumulation of software features? Source: https://ascelibrary.org/doi/10.1061/%28ASCE%29ME.1943-5479.0001079
  • Reviewed:

5x expanded by Partofthemachine (talk). Self-nominated at 05:41, 6 February 2023 (UTC). Note: As of October 2022, all changes made to promoted hooks will be logged by a bot. The log for this nomination can be found at Template talk:Did you know nominations/Software feature, so please watch a successfully closed nomination until the hook appears on the Main Page.

• hmm. I think the article has some prohibitive deficiencies that make it a long way from meeting the DYK criteria – but to your credit, Partofthemachine, articles on broad concepts like this are incredibly tough, so kudos to you for taking it on. First up, we have some sourcing/due weight issues: I see claims about the capability of programming languages sourced to developers, which doesn't demonstrate a need for inclusion in the article. Other sources do similarly seem to lack a rigor that, in aggregate, makes me uneasy. I'm also seeing a bare URL or two. But I think the prohibitive problem is that the article struggles with a scope that is far too broad, and doesn't give any of its multiple definitions enough space to be developed. The background section, for example, consists entirely of hardware features, and the lead doesn't seem to give a clear definition of what a software feature actually is. After having read through the article, I'm not sure I'm actually clearer on the concept – not to mention that the article doesn't really have detail on how a software feature is conceived or implemented, or what the significance of a feature-oriented approach is in the history of software overall.
  A lot of this is inherently pretty subjective, so I understand if you think I'm totally off-base. And while I'll never knock the effort, I don't think the information here is presented in a way that is, in more than surface, an encyclopedic article. There's a lot of good stuff here, but I think it just needs a lot more development. Perhaps you could think about a few ways to focus up the article, maybe tuck the irrelevant stuff away for some later drafts. theleekycauldron (talk • contribs) (she/her) 09:54, 13 February 2023 (UTC)

Examples

A large part of this article is about examples of features, but most is off topic. A naval ship, WT! And a language feature is not what I'd call a software feature. The only real software features are about xterm and that is such an old and niche thing that it's not going to connect with readers. How about features of Windows or iOS or Android ... something normal people use. Stevebroshar (talk) 15:20, 7 April 2024 (UTC)