FeatureKarma

MeatballWiki | RecentChanges | Random Page | Indices | Categories

: "When you initiate new activities, find things you are currently doing that you can discontinue-- whether reports, activities, etc. It works, but you must force yourself to do it. Always keep in mind your TeethToTailRatio." -- Donald Rumsfeld, Rumsfeld's Rules.

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.

[According to] JoeArmstrong?, NiklausWirth? once said that if something is added to a language other things should be thrown away.

Simplicity is beautiful, and beauty is a powerful force in design decisions. People have varying needs, however, and additional features may help individuals achieve simplicity in their work. A feature that most people never use may be a crucial feature to a small group of users.

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.

Another way to compare approaches is to look at various forms of literature. Some people express themselves well at poetry, while others write large novels. Very few people are able to write novels with the intensity of a short poem. (Few people are even able to read intense works of book length.) Sometimes it is appropriate to write a large book to express the details of a simple idea.

Another approach is to just pile on features, and redesign when a problem occurs. For instance, SGML is a carefully designed standard that didn't meet the needs of the early Internet community. HTML was created, and quickly became a mess. Standards emerged from the mess, and some of them (like tables) were accepted and used by the community, while others (like <blink>), were not. Finally, XHTML was created to clean up much of the mess while retaining the useful aspects of HTML.

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.

LinkPatterns and "de facto syntax"

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.

: After several trials, UseModWiki settled on using "" (two double-quotes) as an invisible delimiter, like LinkPatternÿ?0ÿs (displayed as LinkPatterns). It replaced the old practice of using four or six single-quotes like: LinkPatternÿ?1ÿs. The new rule does not interact with any other formatting rules, and it is consistently used for all types of links.

There's nothing wrong with adding features, just as long as you're willing to delete stupid ones.

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.)

Decisions like that are rather easy to make. - Sometimes it's hard. For example, at the moment PageRedirect seems to me to be a "stupid" feature. Its benefits seem minor; mostly it saves us having to follow 1 extra link. Its costs seem major; whenever I look at it I seem to find new complications and problems. So I would be tempted to drop it. On the other hand, I would also be tempted to persevere; perhaps the problems can be fixed with enough work and ingenuity, and the benefit may be greater than I expect.

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.

: The redirect feature took more work than expected, but it is now a "permanent" feature. Enhancements were added to use the HTTP "Location:" header (also useful for ordinary editing), and a link back from the target to the redirected page.

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.

: The "advanced diff" feature saved a few old versions of each page, and could often generate differences from the last time a user read the page. The biggest problem was creating an interface for the large number of options "advanced diff" provided. For some time after I gave up on the "advanced" version, UseModWiki only provided the most basic "diff" feature--the difference between the current and prior version. The current major/minor/author differences are a compromise between the original plans for a full-featured "diff", and the inadequate "prior version" diff.

: Another feature I wanted to write was a "day diff", which would show all changes made on the current day. Because I intended to implement this feature, I resisted the ability for timezone adjustments (which would change the times of the "current day" for various users). After I gave up on "day diff", the timezone adjustments were surprisingly easy. --CliffordAdams

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

: And now (2009) we're turning back to HTML, as we realize content is more important than form, and getting anyone to agree a strict form of the latter is an endless hassle with little merit. Everything old is new again. At least now you only have to pay for features that you use. -- Laurence "GreenReaper" Parry

FeatureKarma

Discussion