If you are suffering from JargonFile:CreepingFeaturitis or, even worse, feature bloat, you have bad feature karma.
Thus, when your fingers urge you to add yet another feature, you have to delete or simplify an existing one to balance the feature karma.
If you believe the perfect computer is off and in a landfill, then you can easily understand this philosophy. Also, if you're working on building a community, the fewer acrobatics you have your constituents perform, the better.
Taken another way, often, the simplest code makes for the best communities because people can grok the behaviour faster. This is because, over time, people slowly reverse engineer the scripts in their head in some way.
If you are allowed few rules, you will make them good and powerful rules. Then, since there are only a few rules, people will learn them all and figure out interesting ways to combine them. This is how Wiki:JimCoplien discovered <TAB><SPACE>:<TAB> == block quote and CliffordAdams figured out how to pluralize LinkPatterns. [Locally the block quote rule is just a : character (at the start of any line), and the plural LinkPattern rule has changed.]
This is in the same vein as the sage writing advice: You are not done editing until you are left with a blank page.
"Writing is easy. You just cross out all the wrong words." -Mark Twain
Keep it simple. Keep it powerful. OrderChaos.
Features can be taken too far, however, especially when less-important features affect common features. Designers should choose good default behaviors, and not overwhelm a user with too many unrequested choices. On the other hand, a good tool should not limit the user to novice behaviors.
It is doubtful that modern HTML could have been designed without the mistakes made in the earlier versions. Many commonly used features (like using "definition lists" to indent text) are now discouraged in favor of later standards (style sheets). Sometimes the best way is to try, fail, learn, then try again with new knowledge. Sometimes one can start the second or third trial system before the perfect design is completed.
Exactly. To balance your karma, you must delete the cruft you've accumulated. There's nothing wrong with adding features, just as long as you're willing to delete stupid ones.
And HTML isn't exactly a good example. There is no standard HTML. It's like trying to port C code before ANSI/X3J11.
Html is the perfect example. There are lots of HTML standards--feel free to choose one. Most browser authors appear to be converging toward the W3C HTML 4 standard.
Accepted standards tend to end innovation. It is likely to be easier to write a whole new language than to add a significant feature to the C standard. (Of course, standardizing the language does nothing to curb the inventive use of the language. An argument could even be made that it encourages it.)
One trick to getting a really good standard is to find out what users really want before freezing the standard. A good way to find out what users want is to implement almost any requested feature, then later see which features are actually used. Some features that seem useful will not be used, while some obscure features will be very popular.
In some ways, adding user-requested features is more important on a Wiki than in most software. If a word processor is missing a feature, one can choose another program that offers the feature. If a wiki doesn't offer a feature, then one doesn't have that option (to just use another program). The content is tied to the particular implementation.
Pluralized LinkPatterns are surely an anti-pattern. The lesson here is that if you don't add a needed feature, people will try to fake it by other means. You end up with a de facto syntax which is unobvious, obscure, verbose, alienating, and generally raises the BarrierToEntry?.
The use of multiple single-quotes to delimit a LinkPattern is certainly not obvious. The interaction with the formatting rules was accidental, and only slowly discovered. In the near future UseModWiki (and MeatballWiki) may add a much simpler solution. The new method will also solve the problem of punctuation after URLs using the same syntax.
If the features were "stupid", they shouldn't have been added, or noticed when they were taken away. Decisions like that are rather easy to make. Treating feature development as a zero-sum game can be harmful to one's user community, by giving people reasons to fight against other people's feature requests. (There will still be competition for limited development time, but sometimes it is easy to grant a low-priority request.)
On the other hand, sometimes tradeoffs are worthwhile. For instance, sometimes a desired feature has too high a cost in development time, or requires restructuring that affects other features.
For instance, an "advanced diff" feature for UseModWiki was developed but later removed. It provided a nearly-optimal "diff" output by keeping a history of page versions within each page. The new code could, given a time, show all the differences since that time, or show the best available difference and alert the user that more differences exist. (For instance, on a 3-day RecentChanges view, the "(diff)" link would show a single diff with all changes over the three days.)
The "advanced diff" feature had several downsides, however. It was hard to test. It made the database much larger. It greatly complicated a few planned "admin" functions, and was often a factor in other plans. The feature was difficult to explain, and could be confusing to use. It wasn't at all fun to write and maintain that code, and it nearly halted other development. Finally, after considering that few people would even use the best parts of the feature, "advanced diff" was dropped. (Maybe it was stupid, but it was really neat when it worked.)
I think I was being overly dramatic when I used the word "stupid." The point I'm trying to make is that it is often better to look for ways to condense features into simpler and more powerful ones instead of adding new frobs to the product. It is stupid, however, to patch on feature after feature without thinking about what you ultimately want from the software and considering what is best. At least that's true in our context as community builders. -- SunirShah
I generally agree. Unfortunately, I'm mostly out of ideas on condensing my wiki code any further. [Warning: questionable metaphor follows ;-] One could think of the process of adding "feature after feature" then simplifying as being like garbage collection. One builds up a bunch of features, then removes those that are no longer useful.
I've had good results with a feature-full strategy in the past. In developing strn, the program began as a simple switch statement within one of trn's functions. After a lot more features were added, the code was moved out to a file and cleaned up. Later, similar functionality was added to a different part by copying and modifying code. Eventually I got tired of modifying multiple parts of code that did mostly the same thing, so I rewrote it in a semi-object-oriented way. (This was before C++ was usable in my environment.)
Several times I found that my earlier guesses were wrong, and drastically changed development directions. (I probably wrote over 20,000 lines of discarded code, compared to about 10,000 lines of delivered code.) At the time, I always saw the code as a prototype model for the final version. The plan was always to extend the current model to its limits, then redesign the project based on what was learned from the model. More than once I made a backup of the source, then removed files from my working directory and rewrote them (to fit a new design). The strn code is certainly not the cleanest C code, but it accomplished some fairly ambitious goals.
If I wanted to justify my method I could call it "organic" as compared to "crystalline" growth. Then again, maybe I just have a messy (dirt-y?) mind (like my desk. :-). I actually like the English-language-like messiness of Perl. --CliffordAdams (who has so much FeatureKarma, he'll probably be reborn as the Microsoft paperclip assistant.)
I've begun to wonder about the redirect feature myself. It actually isn't too bad in code, since most of its function is shared with the redirect after editing. I think that it should be unnecessary most of the time, since people should just change the original links to the real target, then delete the redirect page. I'd like to leave it around for awhile and see if anyone comes up with a good use for it. If the redirect feature is in the way of something else neat, however, it will probably go away.
If you abandon ideas at the first sign of trouble, you'll never achieve anything great. -- DaveHarris
But sometimes you've got to know when to fold them... The "advanced diff" feature nearly killed UseModWiki development. I kept thinking "just a little bit more and it will work" for *months* until I realized that it was a feature only its creator could love. --CliffordAdams (did I mention it was really nifty?)
Yes, you've got to know. I just disagree that the knowing is easy.
Personally I think "diff" is an almost-crucial feature, in terms of having personalised views and scalability. If I visit a site once a week I want to know what changed since then; I just can't afford to reread the entire site each time. (Your recent changes pages succeeds admirably here, by the way.) I also think it's important for accountability, as part of an AuditTrail which I see as an important part of a SoftSecurity model. I don't really understand what your "advanced diff" did, or what the problems were, so I won't say you were mistaken to can it, but I think the general area deserves a lot of effort.
These decisions aren't easy; getting them right is what distinguishes the genius programmers. In Wiki:PatternLanguage terms: Pages like FeatureKarma help because they identify the forces, but the forces still have to brought into balance and this page is too general to offer a concrete solution. The proposed pattern, "Delete an old feature whenever you add a new one", has over-simplified. -- DaveHarris
I like how this page is full of contradictions. These days I consider Cope's indentation hack and Cliff's Wiki:SixSingleQuotes hack and the double-quote delimiter to be ugly, and I think the SGML -> HTML -> XHTML transition doesn't demonstrate anything. Yet still I hold onto the idea of FeatureKarma, if only as a BalancingForce to featuritis. Hey, karma is as hard as it is easy. -- SunirShah